Posted: Wed Feb 24, 2010 8:51 am
Is the CPU frozen during DMA even if it's running from RAM? Because Sega recommends triggering the DMA copy with the source operand in RAM if the copy is from ROM to avoid a hang.
Sega Megadrive/Genesis development
https://gendev.spritesmind.net/forum/
https://gendev.spritesmind.net/forum/viewtopic.php?f=22&t=519
DMA requests the 68k bus, so as long as it is taken, 68k is halted.Gigasoft wrote:Is the CPU frozen during DMA even if it's running from RAM? Because Sega recommends triggering the DMA copy with the source operand in RAM if the copy is from ROM to avoid a hang.
Then why do you have "cycle accurate" claims all over your site?RetroRalph wrote:Since I am using Musashi I needed to handle the case where this happens as it ruins the game display otherwise and Musashi runs on instruction granularity, not cycle.
Hmm I'm not sure how you are handling it but it seems to me if the game is doing a 0x10000 * 2 byte transfer every frame then there are going to be issues. Why would a game do that during the gameplay? It would take upwards of 2 frames if the display is off to transfer it all the while the 68K is frozen completely? If I ignore the 0 length DMA transfer the game is fine which indicates there are other transfers for the game content that make it work. It's an interesting one.Eke wrote:What I am doing is using a cycle count for 68k and a main cycle count for VDP events (line/frame). The main cycle count is incremented by 3420 cycles per line and, as long 68k current cycle count is above the wanted main cycle count, no cycles are executed but other chips (incl. VDP) keeps running.
I think you are mistaken as I have never claimed the Megadrive is completely cycle accurate. It is close though, as every major component besides the 68K is at the cycle level in RetroCopy. The other systems in RetroCopy are completely cycle accurate.notaz wrote:Then why do you have "cycle accurate" claims all over your site?RetroRalph wrote:Since I am using Musashi I needed to handle the case where this happens as it ruins the game display otherwise and Musashi runs on instruction granularity, not cycle.
This kind of DMA is generally done when the screen is blanked (so you don't notice anything if this takes 2~3 frames to complete), between game sequences or at the beginning. It would be very surprising you got a DMA like this during active display with the limited . And yes, treating 0 length as 65536 word transfer is accurate, at least it is required by some games (don't remember which ones).Mmm I'm not sure how you are handling it but it seems to me if the game is doing a 0x10000 * 2 byte transfer every frame then there are going to be issues. Why would a game do that during the gameplay? It would take upwards of 2 frames if the display is off to transfer it all the while the 68K is frozen completely? If I ignore the 0 length DMA transfer the game is fine which indicates there are other transfers for the game content that make it work. It's an interesting one.
Could be the issue.RetroRalph wrote: Also interesting is this game does DMA's without correct VDP codes set, could show maybe they weren't that experienced with the system.
Sure it would... I remember this game is switching display off before the end of a frame and reenable it after the start of the next frame (so play screen is limited by black borders) but that's all. If you got display disabled for a few frames because of DMA, there is definitively something wrong on your side.RetroRalph wrote:This is the state when the DMA is sent :-
If the screen is blanked for 2-3 frames wouldn't this be noticable in other emulators? This DMA is sent repetitively during the actual race meaning if it's actually taken there will be 2-3 frames of blank screen in between every valid frame from the game.
[0(0)][284(284)] VDP register 1 write -> 0x34 (d0dc6)
[0(0)][368(368)] VDP register 19 write -> 0x37 (d0dc8)
[0(0)][368(368)] VDP register 20 write -> 0x1 (d0dc8)
[0(0)][508(508)] VDP register 21 write -> 0x87 (d0dca)
[0(0)][508(508)] VDP register 22 write -> 0xd3 (d0dca)
[0(0)][648(648)] VDP register 23 write -> 0x7f (d0dcc)
[4(4)][14014(334)] VDP register 1 write -> 0x64 (d0de4)
[200(200)][684210(210)] VDP register 1 write -> 0x34 (d0b02)
[200(200)][684210(210)] VDP register 15 write -> 0x2 (d0b02)
[200(200)][684350(350)] VDP register 19 write -> 0x34 (d0b04)
[200(200)][684350(350)] VDP register 20 write -> 0x0 (d0b04)
[200(200)][684490(490)] VDP register 21 write -> 0x1f (d0b06)
[200(200)][684490(490)] VDP register 22 write -> 0x86 (d0b06)
[200(200)][684630(630)] VDP register 23 write -> 0x7f (d0b08)
About that, this is how it's done in Genesis Plus (source address registers as well) but it has not been confirmed to be the case on real hardware, it would need to be tested but it does not seem to break any games so far.When I was updating the length registers after a DMA
Again it's not sure but the most logical is that DMA does not occur when CD0-CD4 are invalid, just as writing VDP data port after setting a read operation does nothing.What should you do with DMAs that aren't set up correctly, ie VBUS DMAs with incorrect code? Would the real machine waste cycles doing them or not even start the DMA?
Well, if you can't afford a flash cart, you could always post test bins for those of us with flash carts to try out. Maybe make a thread specifically for flash testing in the Advanced->Hardware forum.Eke wrote:So many things to test, I wish I had a way to do it myself
If you are referring to how the source and length registers get updated during DMA (and the impact that has on games doing more DMA without re-writing some/all of the DMA registers) then it has definitely been tested on the real thing.About that, this is how it's done in Genesis Plus (source address registers as well) but it has not been confirmed to be the case on real hardware, it would need to be tested but it does not seem to break any games so far.
that's probaly what I will end to do when I have some "free" time.. any tips or code example to display test in a MD program ? I think I have enough for basic MD programming in ASM but am missing an easy-to-use font "library"Well, if you can't afford a flash cart, you could always post test bins for those of us with flash carts to try out. Maybe make a thread specifically for flash testing in the Advanced->Hardware forum.
great, thanks for confirming thisCharles MacDonald wrote: If you are referring to how the source and length registers get updated during DMA (and the impact that has on games doing more DMA without re-writing some/all of the DMA registers) then it has definitely been tested on the real thing.