Distorted sprites on OCS and invisible on ECS

[KONEY]

I have a problem with sprites and tried some thousand different things without finding any clue to what's happening...


Now I'm aware of the OCS bug with sprites 6-7 and I'm staying away from them. But here the problem is with sprites 4-5 as they are vertically stretched. Now I could say I've invented some new real-time bitmap stretching technique but it wasn't my intention


So this is a test screen to show what's happening, numbers "12" are the same bitmap data and are sprites 00 and 04, why on earth #4 is double in height?






Then the "K" is sprite 01 and the red dot is sprite 03, all normal.


but there's even more, on ECS/AGA sprites 00 and 04 simply don't show at all...

Some help anyone, please?



SRC here: https://github.com/KONEY/lost_octame.../TR-808_MAIN.s

[ross]

hehe, you managed to produce several side effects with just one sprite for different chipsets, it wasn't easy

DDFSTRT=$28 for sprite 4 on OCS has the same effect that DDFSTRT=$30 has for sprite 6, i.e. it only fetch the data for a single sprite bit-plane (bpl DMA is back-to-back with sprite DATB DMA).
In practice it is stretched vertically because the second word is placed under the first and so on.

In ECS/AGA it does not work simply because SPRxCTL use bits unavailable in OCS (that are also wrong.. SV9=1 is a bit too much for a PAL screen )

[KONEY]

Thanks Ross, always the first to help n00bz! I knew I was going to screw something up by choosing a resolution of 368x230px Anyway AFAIK this in not documented, I mean it's not clear that the lower DDFSTRT is the more sprites are lost to the digital limbo

I fixed the ECS now, I was so sure the problem was with sprites DMA and didn't check values properly!

But for the OCS bug... is there some way to fix it?

[ross]

Originally Posted by KONEY

But for the OCS bug... is there some way to fix it?

Not for a coexistence of 368px resolution and (full) sprite 4. Isn't 352px enough?
And are you sure that a monochrome sprite 4 is not enough for what you have to do?

[defor]

Originally Posted by KONEY

Anyway AFAIK this in not documented, I mean it's not clear that the lower DDFSTRT is the more sprites are lost to the digital limbo

In HRM defense: In "Maximum Display Window Size" chapter, it says:
"...In addition, it should be noted that using a data-fetch start earlier than ($38) will disable some sprites."
Yeah. It's just a single sentence but it is there

[KONEY]

"SOME SPRITES" because "HALF OF THEM" didn't sound good

[KONEY]

No, resolution needs to be like this. But sprite 4 is monochrome, I'm filling just one plane, subroutine __POPULATESPRITE only fills the first plane. Is that what you mean?

Originally Posted by ross

Not for a coexistence of 368px resolution and (full) sprite 4. Isn't 352px enough?
And are you sure that a monochrome sprite 4 is not enough for what you have to do?

[ross]

Originally Posted by KONEY

No, resolution needs to be like this. But sprite 4 is monochrome, I'm filling just one plane, subroutine __POPULATESPRITE only fills the first plane. Is that what you mean?

Ok, then there are two possibilities to use sprite 4 and that works the same way both on OCS and on ECS/AGA, but since in any case you have to 'populate' it I just tell you one:
- check if you are in ECS/AGA (

btst #13-8,VPOSR

)
- if OCS, populate consecutive words (so only half the sprite memory)
- if ECS/AGA, populate alternate words (full sprite memory)

Beware that the DMA, in OCS case, does not fetch to the latest SPRxCTL, so you may have some side effects and in case you should write it with copper.

However the best thing is that you try by yourself

[KONEY]

I'll try! I guessed there were some way to re-enable sprite DMA with some copper trick?

Writing sprite data from the copper would work because I've already done it but they were dots, in this case I need to put different numbers every second, from a bitmap font... quite intricated!

[ross]

Originally Posted by KONEY

I'll try! I guessed there were some way to re-enable sprite DMA with some copper trick?

Why do you need to reactivate DMA?
Do you need to multiplex sprite 4 on OCS?

[KONEY]

No, but if it helps fixing the glitch why not?

[ross]

Originally Posted by KONEY

No, but if it helps fixing the glitch why not?

If you referring to this phrase:
"Beware that the DMA, in OCS case, does not fetch to the latest SPRxCTL, so you may have some side effects and in case you should write it with copper."
this as nothing to do with 'DMA disable'.

The temporal slot reserved for sprite 4 DATB/CTL fetch is simply stolen by bpl DMA, so it cannot be used (well, technically it is really an OCS bug, but the effect is the same, and cannot be 'fixed'..).

[KONEY]

Thanks Ross! I didn't ask because I mistrust you but just to know a bit more BTW I'm nearly done with the ECS/OCS trick and it looks like the simplest way.

[ross]

Originally Posted by KONEY

Thanks Ross! I didn't ask because I mistrust you but just to know a bit more BTW I'm nearly done with the ECS/OCS trick and it looks like the simplest way.

ah! and this reminded me that you should also set to zero sprite 4 DATB register because the DMA never fill it in OCS, so it could contain some previous data and, combined with the DATA bitplane, create a shape/color that is not the one you wanted

[KONEY]

thanks! I'll check it out!

[KONEY]

@ross like this?

MOVE.W	#0,$DFF166

[ross]

Originally Posted by KONEY

@ross like this?

MOVE.W	#0,$DFF166

Yes, or somewhere in copper-list like:

        ...
	DC.W $13C,0,$13E,0 ; 7
	DC.W $166,0 ;SPR4DATB

[Photon]

Because of DDFSTRT, you get "4.5" sprites; SPR4 is seen as a 1-bitplane sprite and reads the sprite data 1 word per line instead of 2. This results in a stretch visually. It can also lead to the ending control word being missed and therefore unpredictable display of SPR4.

You can make SPR4 a 2-bitplane sprite by increasing DDFSTRT by 2 (4 lores pixels). This can still give a 368px wide display if you also increase DDFSTOP by 2 and adjust the DIW.