Megadrive video timings

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Gigasoft
Very interested
Posts: 95
Joined: Fri Jan 01, 2010 2:24 am

Post by Gigasoft » 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.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Feb 24, 2010 9:16 am

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.
DMA requests the 68k bus, so as long as it is taken, 68k is halted.
The hang that occurs when the code that triggers DMA is executing from ROM is a different issue, I'm not sure why it occurs (maybe because of DTACK not being returned when prefetching next instruction from ROM ?)

notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

Post by notaz » Wed Feb 24, 2010 11:49 am

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.
Then why do you have "cycle accurate" claims all over your site?

RetroRalph
Interested
Posts: 16
Joined: Wed Feb 24, 2010 6:13 am
Contact:

Post by RetroRalph » Wed Feb 24, 2010 1:04 pm

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.
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.

Also interesting is this game does DMA's without correct VDP codes set, could show maybe they weren't that experienced with the system.... or maybe there is some huge bug in my code sending some incorrect VDP commands... :)

RetroRalph
Interested
Posts: 16
Joined: Wed Feb 24, 2010 6:13 am
Contact:

Post by RetroRalph » Wed Feb 24, 2010 1:07 pm

notaz wrote:
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.
Then why do you have "cycle accurate" claims all over your site?
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.

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Feb 24, 2010 2:12 pm

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.
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).
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.
Could be the issue.

DMA operation is triggered if:

(1) code register bit 5 (CD5) is set
(2) DMA_Enable bit in VDP register is set.

then:

VDP reg #23 determines the DMA operation type (fill, copy or from 68k bus)
CD0 must be set to indicate VDP write access.
CD1-CD3 must indicate a valid destination: VRAM, CRAM or VSRAM (in the case of DMA Fill/Copy, it's not sure if destinations other than VRAM are valid).
CD4 is set in the case of VRAM Copy only (to indicate read/write cycles ?)

RetroRalph
Interested
Posts: 16
Joined: Wed Feb 24, 2010 6:13 am
Contact:

Post by RetroRalph » Wed Feb 24, 2010 3:07 pm

This is the state when the DMA is sent :-

addr = 0x4922
code = 1 (vram write)
reg0 = 0x14
reg1 = 0x34 (display off)

reg19 = 0
reg20 = 0
reg21 = 0xcf
reg22 = 0x87
reg23 = 0x7F

therefore :-
dma_address = 0xff0f9e
dma_length=0 (so 0x10000 words)

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 inbetween every valid frame from the game.

I understand why 0 = 0x10000 makes sense for the non VBUS transfers as they are specified in bytes but seems weird to allow the VRAM to be updated with 128KB when it only takes 64KB, and what sort of game programmer would double update VRAM when it's unneeded?

The fact I can ignore it and the game works sort of implies that there may be a bug somewhere else in my code or maybe the understanding of VBUS DMA isn't quite known. If you can remember a game that requires VBUS DMA 0=0x10000 it would me let me know at least it's a bug in my code. :)

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Wed Feb 24, 2010 4:23 pm

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.
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.

EDIT: did a quick check and this game does not set the length register to 0 so there is something wrong in your emulator which is missing some register writes.

here's some debug infos if that helps (the last value is the current PC, i.e next instruction):
[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)

RetroRalph
Interested
Posts: 16
Joined: Wed Feb 24, 2010 6:13 am
Contact:

Post by RetroRalph » Thu Feb 25, 2010 1:26 am

Yes it was a bug. When I was updating the length registers after a DMA I was sending the cached write before that, so if one of them was a reg 19 write it would be overwritten with 0 after the DMA, thanks for your help Eke.

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?

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Feb 25, 2010 8:46 am

When I was updating the length registers after a DMA
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.
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?
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 would also need to be verified is if VSRAM/CRAM code can be somehow used for VRAM fill/Copy operation but it's not officially documented and no games seem to need this.

So many things to test, I wish I had a way to do it myself :roll:

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Feb 25, 2010 6:17 pm

Eke wrote:So many things to test, I wish I had a way to do it myself :roll:
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.

Charles MacDonald
Very interested
Posts: 292
Joined: Sat Apr 21, 2007 1:14 am

Post by Charles MacDonald » Fri Feb 26, 2010 11:05 pm

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.
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. :D

Eke
Very interested
Posts: 884
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Sat Feb 27, 2010 6:15 pm

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.
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"
Charles 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. :D
great, thanks for confirming this :wink:

HardWareMan
Very interested
Posts: 745
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Re: Megadrive video timings

Post by HardWareMan » Fri Jan 27, 2017 12:45 pm

Fileden is died. Who saved those test?

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Re: Megadrive video timings

Post by TmEE co.(TM) » Sat Jan 28, 2017 2:23 am

http://www.tmeeco.eu/Fileden/

Look for same filesnames, I have full backup of all the files I have posted in there. Exactly as my signature here (and everywhere else) says :P
Mida sa loed ? Nagunii aru ei saa ;)
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen

Post Reply