winuae dma debugging
- start WinUAE
- start the program you need to profile/debug
- Press
Shift F12 - In the debugguer prompt, type
v -4. The option range from 1 (nothing shows up?) to 4 where the debug display covers almost the entire screen - Enter
gorgoto restart the CPU - Enjoy!
The debugger displays each DMA/CPU cylce line by line, reading from left to right. The color codes (from the WinUAE source) are the following:
The way in which the priorities are assigned between the different chips and the 68000 is detailed here:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node012B.html
...and here:
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node02D4.html
The DMA Debugger really helps to visualize how DMA priorities work.
- Disk DMA, audio DMA, display DMA, and sprite DMA all have the highest priority level
- 4 cycles for memory refresh
- 3 cycles for disk DMA
- 4 cycles for audio DMA (2 bytes per channel)
- 16 cycles for sprite DMA (2 words per channel)
- 80 cycles for bitplane DMA
- The lowest priorities are assigned to the blitter and the 68000, in that order. The blitter is given the higher priority because it performs (..) much faster than the 68000
Basically, the more bitplanes there are to decode, the fewer cycles available per line for the blitter and CPU. The overscan thus occupies a bit more the DMA (the number of pixels per line to decode is more important) and from the 5th bitplane (in 32 colors, therefore), the CPU starts to miss cycles in favor of the DMA.
"If the display contains four or fewer low resolution bitplanes, the 68000 can be granted alternate memory cycles (if it is ready to ask for the cycle and is the highest priority item at the time)."
The worst being in Hires:
" If you specify four high resolution bitplanes (640 pixels wide), bitplane DMA needs all of the available memory time slots during the display time (..). This effectively locks out the 68000 (as well as the blitter or Copper) from any memory access during the display"