How much of the DMA budget does XGM take?

[cero]

The docs say a NTSC system can DMA 7.6kb per vsync. Since XGM does some processing there, and the DMA protection also affects some, what is the safe DMA budget when using XGM?

In other words, what is the worst-case amount XGM will steal from the DMA budget?

[Stef]

XGM does not take any DMA budget, it's the opposite actually. XGM has protection against DMA so the samples continue to play during DMA operation. For that you need to use :

Code: Select all

SND_set68KBUSProtection_XGM(TRUE);
VDP_doVRamDMA(data, 0x1000, 0x100);
SND_set68KBUSProtection_XGM(FALSE);

Still if you use long DMA (longe than VBlank period) you might consume too much time on the XGM driver which need to access 68K BUS for 4 ch PCM mixing so at some point you will observe lag and PCM mixing troubles on XGM driver but DMA won't be affected.

[cero]

In _vint_callback():

Code: Select all

        if (vintp & PROCESS_XGM_TASK)
            XGM_doVBlankProcess();
            
        // dma processing
        if (vintp & PROCESS_DMA_TASK)
        {
            // DMA protection for XGM driver
            if (currentDriver == Z80_DRIVER_XGM)
            {
                SND_set68KBUSProtection_XGM(TRUE);

                // delay enabled ? --> wait a bit to improve PCM playback (test on SOR2)
                if (SND_getForceDelayDMA_XGM()) waitSubTick(10);

                DMA_flushQueue();

                SND_set68KBUSProtection_XGM(FALSE);
            }
            else
                DMA_flushQueue();

            // always clear process
            vintp &= ~PROCESS_DMA_TASK;
        }

That is, the XGM processing happens before the DMA queue flush - it must reduce the time in vsync available for DMA, no? I'd like to know how much.

[Stef]

Oh sorry you were speaking about that ? Honestly the XGM processing here is really small (just about XGM timing). I guess for the whole (counting the VInt handler call and XMG process) you probably loss about 2 scanlines (at max) on the 38 available, so about 36 scanlines remaining for the DMA_flush() process. I think you can even measure it using background color change but really the overhead is small enough...
It gets bigger if you use :
SND_setForceDelayDMA_XGM(TRUE);
In which case you will lose 1 or 2 extras scanlines to let the XGM driver sometime to process PSG commands safely before DMA happen.

[cero]

Hm, so 7.2kb if you use XGM, and 6.8kb with the XGM extra protection.

I ask about this, because in a game I was writing 4.4kb in the dma queue, and it was lagging on hw. So I wondered if the XGM overhead was big enough to cause that. If the overhead would indeed drop the budget to just 6.8kb, then I need to look elsewhere.

[cero]

I think you can even measure it using background color change but really the overhead is small enough...

How would you measure something that lasts less than a frame with a color change? Emulators only display at 60fps, hw displays at 60fps, and even if you had a 200Hz screen, you'd also need a high-fps camera?

[Stef]

Hm, so 7.2kb if you use XGM, and 6.8kb with the XGM extra protection.

I ask about this, because in a game I was writing 4.4kb in the dma queue, and it was lagging on hw. So I wondered if the XGM overhead was big enough to cause that. If the overhead would indeed drop the budget to just 6.8kb, then I need to look elsewhere.

That is theorical numbers but still you should be close to that yeah. Definitely you have something wrong if you obtain lags with only 4.4 kb in the dma queue. About the color background measurement, actually the idea is about changing background color before a specific method call and restore it afterward so you can measure easily the time spent in your method in number of scanline as they have different background color. The problem is that you have to test on real hardware as i don't know any emulator actually displaying the overscan area at top/bottom of screen.

You can also try to disable the "auto flush" of DMA with :

Code: Select all

 DMA_setAutoFlush(FALSE);

So you can control it yourself in you VInt callback method for instance.
You can try to measure the V counter before and after calling

Code: Select all

DMA_flushQueue();

[cero]

I measured the DMA queue, and it took about 19 lines. Seems I had some too long frames on rarely executed functions, optimized a bit, let's see if that takes care of it.