VRAM to VRAM DMA help

[ccovell]

Hey, folks.  I've tried VRAM-to-VRAM DMA transfers a few times, and every time I try it, it works only once (inside of the 1st VBlank) and never again on successive VBs.

I write as usual to the Source reg, destination, and then length, and it completes successfully, only once.  Cycling on the status register ($0000) only makes the code loop infinitely.  I've tried DMA interrupts on/off as well as putting the transfer at the start of my VBlank code and at the end.

Are there any tricks to getting this to work reliably?  Something I've overlooked?

[touko]

Strange, it works fine for me, even with a DMA list driven by interrupts .
And it works perfectly for the two SGX's VDC too.

Do you start it each time in main loop ??

My only complain is in mednafen i cannot define how many bytes you can transfert really with DMA  ..
It seems that mednafen is not accurate for vram to vram DMA .

[ccovell]

I've tried it in the VSync routine, and also in my main loop outside of VSync.

Can anyone who has had a problem like this and learned how to overcome it give their advice?

[touko]

Are you sure to not have an infinite loop somewhere,mainly in interrupt handler ??
I don't see any reasons for this happening except an infinite loop, or V-int does not happen after the first time .. 

PS:I've tried my DMA routine on mednafen, not the real thing, but i think it should works too .

[Bonknuts]

I've only ever used it for Dragon Warrior nes2pce. I remember it working fine, just disappointed in how fast it wasn't. I needed transfer 8k per frame (vblank time) and it didn't (it did 4k per vblank when switched into 512 pixel res mode for vblank. Maybe I did something wrong. Maybe I had an accidental double frame during vblank because I didn't set the vblank scanlines to be long enough for 512 pixel speed mode, and this cancelling it prematurely). Do you have sprite auto dma flag enabled? Maybe it's an edge case scenario, where sprite dma is preventing it from happening?

[touko]

4k is very slow,i cannot think is slower than MD DMA or snes  , and mainly in 512 pixels ,i have always thought that DMA transfert were about 2 cycles/byte to transfert in accordance with the 93ns VRAM chip needed for 512 pixels res.

4k in 256 pixels,or maybe in 320 (equivalent to MD in this case, but slightly better due to the higher PCE's dot clock), could be correct.But not in 512 ..

Or maybe i missed something ?? 

[Bonknuts]

I honestly don't remember anymore. I was always meaning to do some tests to get some real numbers/understanding, but never did. I think I figured it was one WORD transfer per 8 VDC pixels (which has 8 slots). Weird, cause the SATBDMA transfers two WORDs per 8 VDC pixels (~169 bytes per scanline). If you touch vram during SATBDMA, it'll stall the cpu for 3 scanlines. But I don't remember this being the same for VDMA. Meh, it's been too long...

[touko]

Yes VRAM to VDC is ~170 byte/line, but it seems that this kind of transfert use his own bus because SAT memory is integrated in the VDC circuit, and don't use the VRAM access bus for SAT ram ..
If i'am right, you can only expect 170 bytes/2 for a VRAM to VRAM transfert.
 in H32 ~3ko (85 bytes x 35 lines), the same than Md's DMA ..
3,5 ko for H40 , same than Md's DMA too ..
6ko for H64

Maybe charles has more infos about DMA ??

[Bonknuts]

Maybe, but it could something we could test as well. I just don't have a SDTV to hook my PCE up to currently, to do any real hardware testing.

[Aladar]

Tested years ago: VRAM-to-VRAM DMA transfers one word per 4 VDC cycles.

[Bonknuts]

Tested years ago: VRAM-to-VRAM DMA transfers one word per 4 VDC cycles.

So two WORDs per 8 pixel dot clock (170bytes per 5.37mhz scanline equiv)?

[fragmare]

Tested years ago: VRAM-to-VRAM DMA transfers one word per 4 VDC cycles.

So two WORDs per 8 pixel dot clock (170bytes per 5.37mhz scanline equiv)?

wouldn't that work out to about 6.5KB per vblank if you used 256 x res, 263 line mode with 224 used for displayable scanlines?

[dshadoff]

Kind of curious - how many xfer operations are you trying to do during one vblank ?
In each case, are you waiting sufficient time for the preceding one to complete before setting up the next ?

Or are you saying that you set up one - during the first vblank - and it never works again, on the next vblank or whatever ?

(also sounds like a status register may need to be given an acknowledgement).

Unfortunately, I never did VRAM-to-VRAM DMA... but if I had a problem like yours, I'd look for a commerical game that uses it, and use Mednafen to put a watchpoint on all the VDC ports, and see what it does.

UPDATE: also, Develo Assembler is talking about having IRQ on for EX_SPRDMA to work, so maybe it's related ? (ie. IRQ triggered when DMA xfer complete; IRQ service routine should acknowledge somehow ?).  If you can read Japanese well enough, it's on page 148 of Develo Assembler manual, in the margin.

[touko]

Tested years ago: VRAM-to-VRAM DMA transfers one word per 4 VDC cycles.

It matches with my 2cycles/Byte estimation .
But this 170 bytes/line is calculated for VRAM to SAT DMA, i don't know if this is correct for VRAM to VRAM .

So two WORDs per 8 pixel dot clock (170bytes per 5.37mhz scanline equiv)?

Yes, in 5.37 dotclock you have 341 VDC cycles/line, 2 VDC cycles a byte is 170 bytes/line transfered .

ie. IRQ triggered when DMA xfer complete; IRQ service routine should acknowledge somehow

DMA irqs are off at system start up, if you want DMA irqs, you must activate her yourself .

I think we cannot test DMA safely with mednafen, cause is not accurate at all in this department. .

Develo Assembler is talking about having IRQ on for EX_SPRDMA to work

Irqs related in develo are system irqs, are here just to be careful if you use your own and bypass the system ones .

[Aladar]

From my old tests exactly 168 bytes per line(5 cycles are not used).
With the sync disabled between VDC and VCE the transfer is slighty better because every cycle is used.