Blitter affecting audio?

[Muzza]

In my Turrican AGA conversion, I have an audio problem that I've not been able to understand.

In cases where the blitter use is very high (boss fights), and if a frame is dropped, the TFMX music will sometimes distort slightly.
The music player uses interrupts for vertical blanks (level 3), Audio (level 4) and CIA timer (level 6). They all appear to be working and so I wouldn't expect anything could break the music even during a lost frame.

In fact if I add an artificial delay to intentionally drop lots of frames, the music does continue to play without distortion. It is only when I add in large blits from the boss fights that the problem occurs.

Is it possible that the blitter can cause an interrupt to be missed, or audio DMA slots to be lost? I didn't think that was the case, but I'm low on ideas.

The only other thing done inside the interrupts of any significance is the audio mixer update inside the level 4 interrupt. I've tried disabling it, but no change.

To be honest it is not a massive problem as I've mostly got the blitter usage in the boss fights to a manageable level, but it would still be nice to resolve the root cause. Any ideas would be greatly appreciated.

[roondar]

The Blitter does not affect audio per se, but it can still be the reason for the issue you see.

If you run the Blitter in 'nasty' mode (BLTHOG) then you're locking out the CPU during blits (assuming copy & cookie cut blits here as they're the most common for games). This leads to faster blits, but it also can cause side effects. If an interrupt triggers during a blit, it will be delayed until the CPU gets access to the bus again (which will be after the blit is finished).

In the case of mod player/music/audio interrupts, it's important that they're not delayed by too much, because you'll get audible glitches otherwise. So, if your blits are big enough, it is indeed possible to get to a point where the music related interrupts get delayed too much and you start hearing that. Note that the same also applies for other interrupts, such as the VBL.

A potential solution would be to blit big objects in several smaller blits instead of as one very big blit. That way, there will be a smaller maximum delay until interrupts can trigger again, which should help resolve the problem. Incidentally, the reason why the audio mixer doesn't show this problem is because audio interrupts trigger so early that there is a lot of time for the mixer to catch up before issues become apparent.

[Muzza]

Thanks Roondar. This makes sense. I only turn on blitter nasty at the end of a frame if there is blit work left to do. So I can see it could cause a vblank interrupt delay.
Boss blits are broken up into smaller bits but are still large for some bosses.
I’ll have to think about this some more. Neither turning off nasty nor breaking up blits are particularly appealing at first glance.

[roondar]

It's certainly possible that the VBlank might be pushed down that way. Thought of another 'trick' that might help. You could use the Copper to force the Blitter to non-nasty around the VBlank, so that the music interrupt always gets some time.

[lmimmfn]

Doesnt the Turrican series generally have the large bosses as backgrounds that are scrolled and blits the actual background? , would that be possible? I havnt played PC Turrican 2 so dont know if it is or not.

[Muzza]

Originally Posted by roondar

It's certainly possible that the VBlank might be pushed down that way. Thought of another 'trick' that might help. You could use the Copper to force the Blitter to non-nasty around the VBlank, so that the music interrupt always gets some time.

This worked!

If I clear blitter nasty at the very start of the copper list, this allows the vblank interrupt to be called and the music is free of distortion. It is certainly a more elegant solution than breaking up the blits, or turning off blitter nasty completely (which does have a significant impact on frame timings).
Thanks for the help.

[Muzza]

Originally Posted by lmimmfn

Doesnt the Turrican series generally have the large bosses as backgrounds that are scrolled and blits the actual background? , would that be possible? I havnt played PC Turrican 2 so dont know if it is or not.

I believe the final boss (who is almost full screen in size) is done that way on Amiga Turrican 2. I don't think the regular bosses are though - not sure though.

On that note, is it possible to mask playfields in WinUAE? I thought you could do it with Mb 55 and MB aa, but doing this on original Turrican 2 does not give the results I would expect.
I thought the lives and score must be done using dual playfield, as they don't appear to be hardware sprites, but masking the bitplanes does not separate them from the main playfield.

[Muzza]

Also AGA dual playfield is 16 colours x 2. The first boss alone in the PC version has 73 colours. So I'm unlikely to use dual playfield anywhere in the conversion.

[roondar]

Originally Posted by Muzza

This worked!

If I clear blitter nasty at the very start of the copper list, this allows the vblank interrupt to be called and the music is free of distortion. It is certainly a more elegant solution than breaking up the blits, or turning off blitter nasty completely (which does have a significant impact on frame timings).
Thanks for the help.

You're welcome

Originally Posted by Muzza

On that note, is it possible to mask playfields in WinUAE? I thought you could do it with Mb 55 and MB aa, but doing this on original Turrican 2 does not give the results I would expect.
I thought the lives and score must be done using dual playfield, as they don't appear to be hardware sprites, but masking the bitplanes does not separate them from the main playfield.

It should be possible using Mb and then giving the correct bitplane mask. I've not used that feature much though and I usually get confused as to what order the bits go in when I do

For T2 specifically, it could be possible that the lives/score are just blit on top instead of being on a separate playfield?

[ross]

Originally Posted by roondar

I've not used that feature much though and I usually get confused as to what order the bits go in when I do

It's a binary mask, where lower bits are the lower bplanes.
Example: do you want to see what happens on bplane 3? ->

Mb 4

More: do you want to 'disable' EHB bplane? ->

Mb 1F

[Muzza]

Originally Posted by roondar

For T2 specifically, it could be possible that the lives/score are just blit on top instead of being on a separate playfield?

I think they must be. It's just that they look like prime candidates for hardware sprites and I'm just surprised that an action heavy game didn't take the cheap route.

[aros-sg]

They also wasted memory by having 384 (320+32+32) pixel wide screen buffers (and probably 190+32+32 high). Even if tiles are 32x32 they could blit them as 16x16 and then use 304+16+16 wide buffers.

[pink^abyss]

Originally Posted by aros-sg

They also wasted memory by having 384 (320+32+32) pixel wide screen buffers (and probably 190+32+32 high). Even if tiles are 32x32 they could blit them as 16x16 and then use 304+16+16 wide buffers.

I guess the additional width was chosen to get rid of clipping Bobs on X axis as it makes blitter setup much less complex. I used that approach for 'Tinyus' and 'Wrong Way Driver' too.

[Muzza]

I suppose it depends on whether you are trying to save blitter time or CPU time.
I clip to the visible borders of the screen to avoid any extra overdraw. For objects within the bounds of the screen there is a faster no-clip path for the blits.

[pink^abyss]

Originally Posted by Muzza

I suppose it depends on whether you are trying to save blitter time or CPU time.
I clip to the visible borders of the screen to avoid any extra overdraw. For objects within the bounds of the screen there is a faster no-clip path for the blits.

Yeah, on A1200 i would always prefer to clip instead.
Regardless A500 or A1200 it's a good optimization to never clip <=32 pixel wide Bobs because you usually have that space due to scrolling.

[roondar]

I prefer to either not clip, or to only clip to the nearest 16 pixels (both horizontally or vertically). That way, the overhead for clipping is almost always worth the gain in cycles for not blitting that part of the object. To make that work, I need at least 16 pixels of extra space on all sides of the bitmap. But you normally need some space for scrolling anyway, so it's not such a big deal.

You still pay in cycles for testing if clipping needs to be done I suppose, but that's shouldn't be that many cycles to do (admittedly, I didn't time it).

[aros-sg]

Originally Posted by pink^abyss

Regardless A500 or A1200 it's a good optimization to never clip <=32 pixel wide Bobs because you usually have that space due to scrolling.

Assuming 16x16 tiles, then for scrolling you only need 16 + 16 extra pixels. So for visible width of 320 pixels (max. 21 visible tiles) = 320 + 32 = 352. I don't think that's is enough space for unclipped 32 pixel wide bobs.

[phx]

Originally Posted by aros-sg

Assuming 16x16 tiles, then for scrolling you only need 16 + 16 extra pixels.

With the usual technique (ScrollingTrick.lha) you need three extra columns for horizontal scrolling. Not two.

[aros-sg]

Originally Posted by roondar

To make that work, I need at least 16 pixels of extra space on all sides of the bitmap.

Really? Assuming a non scrolling at all screen with visible 320 pixels. Does it still need to be 320+16+16 internally for clipping to work? That would suck. Can't that be avoided some way by for example using descending blit mode for clipping at the left side.

[aros-sg]

Originally Posted by phx

With the usual technique (ScrollingTrick.lha) you need three extra columns for horizontal scrolling. Not two.

No, only two and you know that because I corrected you about that already once or twice. I wrote ScrollingTrick.lha.