How to calculate possible blit times?

[KONEY]

Thanks, I am aware of this but I'm not sure how to figure out valuable informations from it:





Nonetheless one of my favourite glitch generators

Originally Posted by Rotareneg

You can get a visual display of DMA activity in WinUAE as well: http://eab.abime.net/showpost.php?p=...7&postcount=67

[roondar]

The DMA debugger shows which DMA source is accessing which cycle in Chip Memory on a frame by frame basis. Very useful to see what is doing what and how fast/slow parts of your code are.

Anyway, the colours represent the various DMA channels.
Purple = Sprites
Yellow = Copper
Red = audio
Dark Red & Gray = CPU (read/write)
Dark gray = memory refresh
Cyan = Blitter
Blue = Bitplanes
White = Disk

The screenshot you've shown here shows that almost the entire frame is spent blitting, with a pretty big chunk of DMA reserved for bitplanes as well.

[KONEY]

Ok, thanks. I can spot where my copper waits are and where the blue part gets thicker is because bottom 12 pixel are in hi-res.

Starts to make some sense, the blue part is basically the display area where bitplane DMA usage intensify. Up, down, right and left parts are where the beam is not drawing. Is this the correct way to read it?

What still doesn't make sense to me are these two profiles, using a less intense blitter routine.

Audio playback off, scroll is smooth:


Audio playing back, scroll is jerky:


Blitter DMA usage is far from being full and yet scrolling is affected by audio. Scroll is vertical and happens between upper and lower copper waits. There's a part where audio and blitter are together, maybe this is the point?

[KONEY]

Sorry, just noticed your reply!

Originally Posted by Galahad/FLT

If you were not running an interrupt before, it could be that your code was running close to going over a frame, and now that you've introduced an interrupt is what makes it fall over.

I checked this by poking $dff180 just before branching to mainloop and there's a good amount of raster time left.

Originally Posted by Galahad/FLT

Firstly, what playroutine are you using? if its anything other that PHX's playroutine, it could be because of a cpu delay or a dma wait that is too large.

OctaMED playroutines from Aminet, heavily fixed by me so maybe I can fix this DMA wait problem.

I'm pretty sure I had a similar problem using P61 some time ago but it was my first intro and I never worried too much. Still I think the main reason is samples' rate, I tend to digitize at maximum frequency and use high notes to keep up sound presence so music for sure is moving more data than the average .mod

Originally Posted by Galahad/FLT

Secondly, starting an interrupt, exiting and RTE according to Toni Wilen uses as much as 70 cycles, if your code is close to running over a frame, the processing of the interrupt could be enough to make it go over.

This is what happens with CIA timers calling music routine, right? And can happen anytime, so checking raster position by poking as I mentioned doesn't count? is this what you mean?

Originally Posted by Galahad/FLT

Also, where have you placed your blitter waits? Before the blit code you want to execute or after?

Before, specifically before setting anything new on any blitter register.

[roondar]

Originally Posted by KONEY

Blitter DMA usage is far from being full and yet scrolling is affected by audio. Scroll is vertical and happens between upper and lower copper waits. There's a part where audio and blitter are together, maybe this is the point?

This sounds like it might be a 'race condition' to me. When do you update the Copper pointers?

See, it's possible the interrupt for the mod player moves the CPU writes to the Copper/Copperlist slightly in the frame, and that may be exacerbated by the using the Blitter at the same time.

Which could mean that updating the Copperlist without audio still happens (just) in time, but with audio it's shifted in time by the audio DMA/mod player interrupt just enough to occasionally miss the correct time and instead update slightly too late.

[KONEY]

I never update pointers in Copperlist, I assumed it's not necessary as I'm not double buffering.

Usually I go for double buffering when frames don't finish drawing in time and they flicker but in this case (and I think it's strange) there's no flickering, just scroll isn't smooth.

[roondar]

Originally Posted by KONEY

I never update pointers in Copperlist, I assumed it's not necessary as I'm not double buffering.

Usually I go for double buffering when frames don't finish drawing in time and they flicker but in this case (and I think it's strange) there's no flickering, just scroll isn't smooth.

Right, I should've been more clear - this holds for updates to the bitplane shift registers/pointers in the Copper list as well. If those are done through the Copper list, what I said could still hold. However, if that is the case, it should only cause the odd jitter/judder, not a generic slowdown.

If not and you write them directly with the CPU instead, I'm not so sure what's causing it. Looking at the Visual DMA Debugger screenshot you showed, you certainly seem to have enough raster time to do the scroll, play the audio and do the blits.

[KONEY]

Thanks, knowing it sounds strange to someone more expert than me is somehow giving me hope

BTW, bpl pointers ARE poked from the Copperlist but set in the init part and never change.

[paraj]

So what you're experiencing is this (correct me where I'm wrong): Without music you're scrolling some graphics and everything is fine, but then you enable music and the scrolling is jerky, but glitch free and music playback is also OK? And you seem to have enough raster time after your mainloop (as confirmed by setting color 0)?

I'd verify/change:

• Do you really have raster time after your mainloop? Make sure you're not resetting color 0 in your copper list to get wrong results. Add more changes from both CPU and copper to make sure you know exactly what's happening each frame.
• Check how you're deciding on when/how to scroll - if it's time based is it really updated every frame, if it's input based is then input really checked every frame
• Disable the highres part and see if it makes a difference, if that fixes it, change it to e.g. 4 bpl lores (even if it corrupts the display)
• Comment out different parts of the code / display list (in the copper) until things work as expected.

[roondar]

Originally Posted by KONEY

BTW, bpl pointers ARE poked from the Copperlist but set in the init part and never change.

Setting the pointers only once means that my guess can't be it.

I'm with paraj on this one: check to make sure you really do have raster time free (what is the CPU doing all frame, mostly just a busy wait or is there more going on?) and try to eliminate parts of code until you find the culprit.

[Galahad/FLT]

Originally Posted by KONEY

Thanks, now I have a better picture! Actally I'm blitting 2x 320+234 bitplanes every frame. Not sure it can be considered big.

If you mean 320x234, its quite big.

Have you experimented with blitting the first bitplane you want to do, then blitting half the second bitplane, and getting the processor to copy the other half of the second bitplane?

Benefit is as you're using blitwaits before all blitter operations, means your cpu copy routine will be able to run at the same time the blitter is doing the first half of the second bitplane.

[KONEY]

Originally Posted by paraj

I'd verify/change:

• Do you really have raster time after your mainloop? Make sure you're not resetting color 0 in your copper list to get wrong results. Add more changes from both CPU and copper to make sure you know exactly what's happening each frame.
• Check how you're deciding on when/how to scroll - if it's time based is it really updated every frame, if it's input based is then input really checked every frame
• Disable the highres part and see if it makes a difference, if that fixes it, change it to e.g. 4 bpl lores (even if it corrupts the display)
• Comment out different parts of the code / display list (in the copper) until things work as expected.

Thanks! Points 2, 3 and 4 I already checked but point 1 put me in the right direction and I think I figured out what the problem is! In short, (Photon's) startup code had this on beginning of mainloop:

    

MOVE.W    #$12C,D0            ; No buffering, so wait until raster
 BSR.W    WaitRaster        ; is below the Display Window.

As the comment suggests its function is to prevent changes to the frame until it has been completely displayed.

Now, audio routine is attached to a CIA timer therefore it can and will kick in any raster position, sometimes more than once per frame. This would add random delays to the overall execution of code and when execution ends after $12C another complete frame was skipped in order to wait again for that position.

Actually frame wasn't skipped but displayed twice then next frame would be drawn completely and this also would explain why no flickering but slowdowns.

Removing the wait everything runs twice the speed which is basically that half blitter DMA free from my profiles. Of course this is not correct and I need to put another kind of wait but this is a topic for another post, for now I can say audio playback at high pitch would take more rasterlines but not affect blitter operations to a point where it slows down.


Thanks for the help!

[KONEY]

Originally Posted by Galahad/FLT

Have you experimented with blitting the first bitplane you want to do, then blitting half the second bitplane, and getting the processor to copy the other half of the second bitplane?

No, but sounds like a good optimization to try!