PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: ccovell on December 08, 2014, 05:36:49 PM
-
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?
-
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 .
-
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?
-
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 .. :-k
PS:I've tried my DMA routine on mednafen, not the real thing, but i think it should works too .
-
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?
-
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 ?? :cry:
-
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...
-
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 ??
-
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.
-
Tested years ago: VRAM-to-VRAM DMA transfers one word per 4 VDC cycles.
-
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)?
-
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?
-
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.
-
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 .
-
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.
-
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.
Are for all kind of DMA ??
-
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).
I only do one DMA... tried 256 words up to 1024 words...
Acknowledgement, if it means reading $0000 each VBlank, yeah, that gets done automatically by MagicKit's include code.
-
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.
Are for all kind of DMA ??
Tested only VRAM to VRAM DMA.
Results:
- 5.37 MHz: 168 bytes/line.
- 5.37 MHz (no VDC-VCE sync): ~170.5 bytes/line (with HSW=2, HDS=2, HDW=$1F and HDE=4).
- 7.16 MHz (no VDC-VCE sync): 227.5 bytes/line.
-
Aaaah, this is excellent ... :D
-
Holy crap, that is fast: just think of 10.74mhz mode O_O
Now I'm really sad that the PCE didn't get the full 128k vram :/
-
Holy crap, that is fast: just think of 10.74mhz mode O_O
Now I'm really sad that the PCE didn't get the full 128k vram :/
And for SGX ???, 13ko for each VDC in 512 pixels ..
-
Chris have you solved your DMA problems ???
I experienced a DMA problem when an auto DMA SAT update and a DMA VRAM->VRAM transfert occur at same time .
DMA vram->vram seems to be occur only once, or your sprite update can be also corrupted .
I think,is not good if the two DMA occur at same time, and one can be corrupted by the other if they are at the same time .
Soluce: Do a manual SAT DMA transfert, or start a vram->vram transfert when SAT update is entirely done (with DMA int) .
-
Soluce: Do a manual SAT DMA transfert, or start a vram->vram transfert when SAT update is entirely done (with DMA int) .
Just in case this helps clarify what you're seeing ...
VRAM-SATB Block Transfer Source Address Register:
The VRAM-SATB block transfer source address register specifies the source start address for a VRAM-SATB block transfer.
The block transfer will not work normally if this register is updated during the VRAM-VRAM transfer cycle.
That warning applies when writing to any of block transfer registers (10, 11, 12 or 13) while a transfer is still in progess.
I'd guess that VRAM-SATB auto-repeat falls under this same restriction.
-
Just in case this helps clarify what you're seeing ...
In my sgx shmup SATB dma is not finished correctly, and sprites are not updated correctly (some are fixed on screen) ..
That warning applies when writing to any of block transfer registers (10, 11, 12 or 13) while a transfer is still in progess.
I do this at start of my frame (normaly all SATB dma were done), i set the dma vram->vram registers (for starting immediatly when vblank occur),and sometimes sprites are not entirely updated, or vram DMA is corrupted .
For information, i use the two VDC (sgx) int for vram dma ..
-
Just in case this helps clarify what you're seeing ...
In my sgx shmup SATB dma is not finished correctly, and sprites are not updated correctly (some are fixed on screen) ..
That warning applies when writing to any of block transfer registers (10, 11, 12 or 13) while a transfer is still in progess.
I do this at start of my frame (normaly all SATB dma were done), i set the dma vram->vram registers (for starting immediatly when vblank occur),and sometimes sprites are not entirely updated, or vram DMA is corrupted .
For information, i use the two VDC (sgx) int for vram dma ..
So you've checked the DMA flag to make sure SATB dma finished? Maybe it's possible that you're getting double satb dma's in a single VCE frame. If you set the "vblank" frame to something really big (200 lines), it should prevent this (I've seen quite a few commercial games do this).
I'd love to confirm some of these things, but I don't have a monitor to run my real system yet - so I can't test anything :/
-
So you've checked the DMA flag to make sure SATB dma finished?
No only try to enable satb dma int, but with no success(but i think this is because i use the system cd irq handler) .
-
I haven't looked at this since my last post, but I believe my code didn't even use sprites, and had SPR-RAM DMA disabled, etc. Still, the VRAM to VRAM DMA didn't work. All a mystery.
-
I solved my problem, i start my first DMA directly in vblank, and not in my main loop like before .