Is DMA useful ?

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Dec 19, 2006 10:32 am

Yes thats true, on Gens it could ran over 40FPS but on real HW it didn't go over 25.

Fonzie · Post by **Fonzie** » Sun Jan 18, 2009 12:18 am

Ok, I have a little question that is regarding "should I dma or not"...

I want to transfert 512 bytes from a fixed ram location into vram...
But I'll have to do a lot of 512 bytes transferts, that may occur during v_active mainly...

I tried to do little dmas of 512 bytes....
And also tried to do 68K moves using long (32bit) moves (all the 128 moves beeing unrolled).

I get similar speed for both (with even a slight speed up for the 68k transfert, at least on emulator)... Is that normal?
I mean, I just do :

*dataport=*buffer;buffer++;
*dataport=*buffer;buffer++;
*dataport=*buffer;buffer++;
...
128 times

I just would like to know if my results are absurds or if its normal that 68K is faster for that kind of transferts, especially during Vactive.

Thanks

Jorge Nuno · Post by **Jorge Nuno** » Sun Jan 18, 2009 12:54 am

I think that during active video the transfer speed is the same, but the DMA has a pre-initialisation procedure, and the 68k moves don't (at least not as big as DMA), so in active short transfers, or in vblank tiny transfers, 68k wins.

Maybe turnoff video generation during the transfer?

I'm not sure if during hblank the DMA is full-speed, because the VDP is reading sprites from VRAM in that timeslice (but they could be read using only the SA port, and the PA port could be free to DMA access..)

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun Jan 18, 2009 1:51 am

You can transfer 32 bytes during a line in active scan into CRAM, I think you can transfer 32bytes into VRAM also during a active line. I start updating VRAM as soon as my game code finishes, wether it is during active scan or not, access happens in all cases and there's no point in letting any to be wasted. When doing active scan transfers, you should be careful with some things to avoid visual artifacts... i.e don't update sprite table until all sprites are shown, otherwise you get nice effects

Fonzie · Post by **Fonzie** » Sun Jan 18, 2009 9:23 am

Jorge Nuno > Well, I can't turn off video as its displaying something.

Umm, 32 bytes/line of display... Are you sure?
Because it would mean that you could DMA 224 tiles during active period, and I have some doubts about it ^^.

Hoooo god, that's nerdism to the max

Nobody want to do a song about this "should I dMA or should I ..." ^^

Stef · Post by **Stef** » Sun Jan 18, 2009 7:31 pm

Fonzie wrote:Jorge Nuno > Well, I can't turn off video as its displaying something.

Umm, 32 bytes/line of display... Are you sure?
Because it would mean that you could DMA 224 tiles during active period, and I have some doubts about it ^^.

Hoooo god, that's nerdism to the max Nobody want to do a song about this "should I dMA or should I ..." ^^

Actually you can turn off display during active period.
Mickey Mania does it during the "3D run" level.
It does desactivate the display just at the Hblank start period, start the DMA and reactivate immediatly the display, i believe all that is done with 2 writes to the VDP port (one 32 bits and one 16 bits).
To optimize your cycles you can use the H counter and verify when you can start to desactivate the video in H blank without impacting the video refresh.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun Jan 18, 2009 7:55 pm

This is DMA to CRAM every line, there's 16 distortions, and each distortion means single word that gets written into CRAM...
I don't know if it applies to VRAM transfers, I guess not... I'll have to figure out some tests...

Jorge Nuno · Post by **Jorge Nuno** » Sun Jan 18, 2009 8:09 pm

I've noticed those dot's in active display before (water in sonic), but I didn't noticed the fact that the "distance" between them is different. It seems that the new color is written every 16 pixels. but in some areas the gap is 32 pixels wide, and in the right area there are 2 writes with a gap of 1 pixel.

How about 256pixel mode?

The topic looks distorted

TMorita · Post by **TMorita** » Sun Jan 18, 2009 8:19 pm

ob1 wrote:Hi you all.
I'm wondering a silly question : is DMA useful ?
I'm talking about DMA 1 : transfer data from ROM/RAM to VRAM, not DMA-fill or DMA-copy.
...
You have a bigger experience than I. So tell me. In what case is DMA transfer useful ?

It's useful for many things.

On most games the sprite is downloaded dynamically during the VBLANK because the sprites move around, and DMA is used for this since it's faster than using the CPU.

The Zombies Ate My Neighbors game engine uses DMA very heavily. The background engine updates the edges of the character map as chars become visible as the screen scrolls. The sprite engine dynamically downloads both sprite definitions and sprite lists during the vblank every frame. There's a caching scheme used so if the sprite is already in vram, it's not downloaded again, so it doesn't use waste DMA bandwidth.

Toshi

Nemesis · Post by **Nemesis** » Sun Jan 25, 2009 2:29 am

Jorge Nuno wrote:I've noticed those dot's in active display before (water in sonic), but I didn't noticed the fact that the "distance" between them is different. It seems that the new color is written every 16 pixels. but in some areas the gap is 32 pixels wide, and in the right area there are 2 writes with a gap of 1 pixel.

How about 256pixel mode?

I posted a little bit of info about this behaviour awhile back. What you're seeing are the "slots" in which the FIFO is allowed to perform a write during active scan. Since writing to the CRAM during active scan causes the current pixel being drawn at that instant to be corrupted, cram writes visually highlight these slots on the screen. I posted a couple of test roms demonstrating this behaviour, and a couple of videos of them running on the hardware, in this thread:
http://www.spritesmind.net/_GenDev//for ... =5347#5347

Jorge Nuno · Post by **Jorge Nuno** » Sun Jan 25, 2009 2:39 am

Yes, but it is weird that the time it takes to commit the FIFO's new colors into CRAM is not constant in the active raster.
Maybe the VDP is doing VRAM refresh.

FACT: All 256 VRAM rows need to be refreshed at least every 4ms (It stores the bits in tiny capacitors, which will discharge overtime)..
[Speculation]
If the VDP is refreshing in those spots where colors are not written, when they should, it gives:

53.2034MHz/8 = 6.65MHz pixel clock;
The huge gaps are spaced 64 pixels;
6.65MHz/64 = 103.913kHz: this is the refresh counter clock;
How much time it takes to count from 0 to 255 using this frequency?
It takes 256/103.913kHz = 2.464ms < 4ms: VRAM contents are preserved.
[/Speculation]

Nemesis · Post by **Nemesis** » Sun Jan 25, 2009 4:33 am

...Wow, that would actually explain a lot. If you look at one of the videos I posted, you'll see that each of those "gaps" where you might expect one of those bars to appear, but no writes occur, actually extend into the borders. Check this video:
http://nemesis.hacking-cult.org/MegaDri ... v28h40.avi

Can you see how the writes in the borders never occur along particular lines? I never actually knew why that was. I figured it was some kind of internal process which prevented access to memory while it was running, but I didn't know what kind of process would need to be run that regularly, and in the border regions as well. A memory refresh cycle would make sense.

Jorge Nuno · Post by **Jorge Nuno** » Sun Jan 25, 2009 11:49 am

It's barely visible, but yeah, they occur exactly where the color writes should take place, in the active lines.
It could be the refresh timer expiring, as refresh is independent of everything else in the cheap implementations

With CRAM DMA should be the same.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun Jan 25, 2009 2:12 pm

In Sonic3, first stage, the water line without garbage is achieved by setting up a tiny 6 byte DMA transfer (3 colors) and triggering it as soon as HBL kicks in, this way you get the CRAM writes done before useful stuff is displayed on a line, and you get the color write artifacts on the overscan, 1 is separate and 2 are close together like on the pic I posted.

HardWareMan · Post by **HardWareMan** » Sun Jan 25, 2009 3:52 pm

Here I already shown one simply method, to look, how VDP utilize its own VRAM in active scan of raster.

As can be seen in video, the image is divided into 6 equal parts (I think in the 32-tiles mode they will be 5). First 5 (Section 1 - Section 5) are used for rendering plans A and B. Last one, 6 section is used for rendering sprites. You can see that the sections shifted to left (relative to the active raster), which is logical - picture needs a little advance preparation, to compensate for the delay in the schemes. In each section takes place 4 times read from VRAM to SO. Meanwhile, the rest of the time likely to be used by the processor. If you calculate that 40-tiles mode (320 pixels), it will mean that at one section accounts for 40 / 5 = 8 tiles (or 64 pixels), and one subsection 8 / 4 = 2 tiles (16 pixels). Section 6 seems totally preoccupied sprites reading, and shows that sprites coordinate Y is match, and the coordinates of X formed during basic raster drawing. But VRAM speed is limited. And size of sprite buffer inside VDP is unknown. So, maybe this is why we've got that limitation of srites per line?

SpritesMind.Net

Is DMA useful ?

Re: Is DMA useful ?