English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 09 January 2022, 19:10   #21
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
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




Quote:
Originally Posted by Rotareneg View Post
You can get a visual display of DMA activity in WinUAE as well: http://eab.abime.net/showpost.php?p=...7&postcount=67
Attached Thumbnails
Click image for larger version

Name:	DMA.PNG
Views:	180
Size:	57.9 KB
ID:	74347  
KONEY is offline  
Old 09 January 2022, 23:58   #22
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,114
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.
roondar is offline  
Old 10 January 2022, 01:02   #23
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
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?
Attached Thumbnails
Click image for larger version

Name:	DMA.PNG
Views:	164
Size:	19.3 KB
ID:	74351   Click image for larger version

Name:	DMA2.PNG
Views:	162
Size:	20.3 KB
ID:	74352  
KONEY is offline  
Old 10 January 2022, 01:27   #24
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
Sorry, just noticed your reply!



Quote:
Originally Posted by Galahad/FLT View Post
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.


Quote:
Originally Posted by Galahad/FLT View Post
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


Quote:
Originally Posted by Galahad/FLT View Post
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?


Quote:
Originally Posted by Galahad/FLT View Post
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.
KONEY is offline  
Old 10 January 2022, 11:36   #25
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,114
Quote:
Originally Posted by KONEY View Post
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.
roondar is offline  
Old 10 January 2022, 15:05   #26
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
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.
KONEY is offline  
Old 10 January 2022, 15:54   #27
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,114
Quote:
Originally Posted by KONEY View Post
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.
roondar is offline  
Old 10 January 2022, 18:47   #28
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
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.
KONEY is offline  
Old 10 January 2022, 20:43   #29
paraj
Registered User

 
Join Date: Feb 2017
Location: Denmark
Posts: 170
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.
paraj is offline  
Old 10 January 2022, 23:17   #30
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,114
Quote:
Originally Posted by KONEY View Post
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.
roondar is offline  
Old 10 January 2022, 23:55   #31
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 48
Posts: 8,278
Quote:
Originally Posted by KONEY View Post
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.
Galahad/FLT is offline  
Old 11 January 2022, 09:20   #32
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
Quote:
Originally Posted by paraj View Post


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:


Code:
    

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 is offline  
Old 11 January 2022, 09:24   #33
KONEY
OctaMED Music Composer

KONEY's Avatar
 
Join Date: Jan 2009
Location: Venice - Italy
Age: 47
Posts: 591
Quote:
Originally Posted by Galahad/FLT View Post
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!
KONEY is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Calculate offset using labels Beska Coders. Asm / Hardware 7 09 May 2016 19:56
Fastest way to blit things on screen Shatterhand Coders. Blitz Basic 13 03 February 2016 11:12
Calculate Time-Tracks Pixel width? AGS Coders. General 22 10 March 2015 20:19
Calculate a color gradient. AGS Coders. Asm / Hardware 13 11 February 2015 12:20
[BlitzBasic] blit outside bitmap error Raislin77it Coders. Blitz Basic 8 08 February 2014 12:42

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 10:18.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.08319 seconds with 16 queries