Sprite coincidence bit

[Willsy]

Is it possible to read the sprite coincidence bit via CRU, and if so, can somebody post some example code?

 

I have an issue where I'm wanting to check the coincidence bit, but the TI ISR has already read the VDP status, thereby clearing it. I might be able to find a workaround, but if not, I'll have to bitbang the hardware (assuming that I can). Sometimes posted some code that reads the VSYNC bit via CRU but I don't know where he got the info from - hence my question!

 

I'll keep digging..

[Willsy]

Maybe I can get it from >837B... ED/AS manual page 405:

 

The VDP status byte. It is a copy of the VDP status Register.

Bit 0 is the 60 Hz VDP interrupt. It is on every time the screen is updated and off when the bit is read.

Bit 1 is on any time there are five or more sprites on a line.

Bit 2 is on any time that sprite coincidence occurs.

Bits 3 through 7 contain the number of the fifth sprite on a line when there are five or more sprites on a line.

As I understand it, this value is loaded by the console ISR due to the very fact that reading the VDP status byte clears it. I think this'll solve my issue.

Edited October 9, 2015 by Willsy

[Opry99er]

Whatcha workin on Willsy? I sense a great disturbance in the Forth....

[+Lee Stewart]

Maybe I can get it from >837B... ED/AS manual page 405:

 

 

As I understand it, this value is loaded by the console ISR due to the very fact that reading the VDP status byte clears it. I think this'll solve my issue.

 

Yes. I would guess that, as long as you allow interrupts at least 60 times a second, you will capture it. This is probably good enough for TF because I don't think you use sprite automotion. With sprite automotion, you can set up motion conditions that are fast enough to cause periodic missing of coincidence.

 

...lee

[Willsy]

Whatcha workin on Willsy? I sense a great disturbance in the Forth....

 

Ah! The Forth is strong in you!

 

I have a COINC word that does sprite coincidence checking.

 

COINC ( tolerance sprite1 sprite2 -- flag )

 

It's not a pixel level coinc, it's a simple delta between the coordinates. if coordinates<tolerance then it's a hit. However, it tries to be clever. It first checks the hardware coincidence bit. If its *not* set then it doesn't bother doing the coordinates check. Before any of this happens, I let interrupts run with a LIMI 2/LIMI 0 sequence. That was tripping me up, as I was then reading VDPST which had just been cleared by the console ISR. Sometimes it worked, (depends where you are in the frame) but mostly not. Changing it to >837B fixed it.

 

I think your COINC is much more sophisticated than mine?

[Opry99er]

LOL!!

 

Cool. I was just reading up on some COINC info on the TF site for a dual-development project.

[+Lee Stewart]

 

I think your COINC is much more sophisticated than mine?

 

Presuming this line is to me, my code is basically lifted from TI Forth. Here is the high-level Forth code upon which my fbForth ALC is based. The contents of the stack are shown at almost every line. It was how I kept track of what was happening to aid in writing my ALC:

 

 

 

HEX

: DXY ( x1 y1 x2 y2 --- x^2 y^2 )

ROT ( STACK: x1 x2 y2 y1)

- ABS ( STACK: x1 x2 |y2-y1|)

ROT ROT - ABS ( STACK: |y2-y1| |x2-x1|)

DUP ( STACK: |y2-y1| |x2-x1| |x2-x1|)

* SWAP ( STACK: |x2-x1|*|x2-x1| |y2-y1|)

DUP * ( STACK: |x2-x1|*|x2-x1| |y2-y1|*|y2-y1|)

;

: SPRDISTXY ( dx dy spr# --- dist^2 )

SPRGET ( STACK: dx dy sdx sdy)

DXY ( STACK: dx^2 dy^2)

OVER OVER ( STACK: dx^2 dy^2 dx^2 dy^2)

+ DUP >R ( STACK: dx^2 dy^2 dist^2 R: dist^2)

OR OR 8000 AND ( highest bit of dx^2, dy^2 or dist^2 = 1?)

( STACK: flag R: dist^2)

IF ( highest bit = 1)

R> DROP 7FFF ( STACK: 7FFFh)

ELSE ( highest bit = 0)

R> ( STACK: dist^2)

THEN

;

: SPRDIST ( spr#1 spr#2 --- dist^2|7FFFh )

SPRGET ( STACK: spr#1 dx2 dy2)

ROT ( STACK: dx2 dy2 spr#1)

SPRGET ( STACK: dx2 dy2 dx1 dy1)

DXY ( STACK: dx^2 dy^2)

OVER OVER ( STACK: dx^2 dy^2 dx^2 dy^2)

+ DUP >R ( STACK: dx^2 dy^2 dist^2 R: dist^2)

OR OR 8000 AND ( highest bit of dx^2, dy^2 or dist^2 = 1?)

( STACK: flag R: dist^2)

IF ( highest bit = 1)

R> DROP 7FFF ( STACK: 7FFFh)

ELSE ( highest bit = 0)

R> ( STACK: dist^2)

THEN

;

: COINCALL ( --- f ) ( bit set if any two sprites overlap )

837B C@ 20 AND 20 = ( <--may work better than 8802)

;

: COINCXY ( dx dy spr# tol --- f )

DUP * DUP + >R

SPRDISTXY R>

> 0=

;

: COINC ( spr#1 spr#2 tol --- f ) ( 0= no coinc -1= coinc )

DUP * DUP + >R ( STACK: spr#1 spr#2 R: tol*tol+tol*tol)

SPRDIST R> ( STACK: dist^2 2*tol^2)

> 0= ( within tolerance? STACK: flag)

;

 

 

 

I can post the corresponding ALC I used in fbForth, if you like.

 

...lee

 

PS: Forgive the intrusion if you were, indeed, addressing Owen with the above line.

Edited October 9, 2015 by Lee Stewart

[Opry99er]

Schwartz reference?

[+OLD CS1]

Schwartz reference?

 

Nobody's Forth is bigger than anyone else's.

[Tursi]

 

Yes. I would guess that, as long as you allow interrupts at least 60 times a second, you will capture it. This is probably good enough for TF because I don't think you use sprite automotion. With sprite automotion, you can set up motion conditions that are fast enough to cause periodic missing of coincidence.

 

...lee

 

Reading the COINC bit directly won't fix that anyway -- the collision is missed because the sprites jump far enough that they never touched. (Except in XB, of course, where it may be many frames between CALL COINCs, so you could miss there for pure timing).

 

If the ISR is running, yes, the mirror in scratchpad is the preferred way to access the status byte. Unless you are trying to do raster-level effects, it will be as accurate as reading the VDP directly.