Page 5 of 9

Posted: Tue Apr 07, 2009 8:34 am
by Eke
yeah, the DMA is triggered and display re-enabled in the same instruction but according to my logs:

- DMA type is Copy to CRAM (or VSRAM), which means the DMA rate is 205 words per line (don't forget display is disabled which is equivalent as DMA during vblank !)
- DMA length is 16 words which mean 68k should be frozen during
16x(3420/7)/205 = 38 CPU cycles

There seems to be a problem with your DMA cycles calculation, it should not be that long (the display OFF/DMA trick is used for that reason) and should easily remains in the HBLANK period

(Also, be sure you are handling long writes correctly, upper word first)
I really doubt you can freeze the CPU in the middle of instruction. At least you can't interrupt it like this for sure. There is some delay between writing the command and actual DMA start/CPU freeze anyway
well, according to the 68k user manual, Bus Access is granted between memory cycles so theorically, this could happen.

but you are right, VDP reaction is not immediate and the end of the next memory write cycle (end of instruction) would probably be executed before the VDP sends a Bus Request

It's also very likely that in this case, the VDP would also disable the display AFTER the DMA operation has been finished, so that the DMA operation benefits of higher transer capacity.

This is how it was originally coded for and the way you should emulate it I think.

Posted: Tue Apr 07, 2009 9:09 am
by mickagame
If I disable my DMA update when display is swicthed ON/OFF the game works perfectly.

In fact, in order to emulate precisely dma transfer, i do that :
- When DMA is started, i calculate cycles remaining according to DMA type and period type (blanking or not) and i planify an event (VDP_DMA_END).
- During the transfer, if display is switched ON/OFF or VBLANK period start, i update my dma : i calculate bytes remaining, cycles remaining (according to new period type) and change the time VDP_DMA_ENd occurs.

So :
- If display is switched off, the event will happen earlier
- If display is switched on, the event will happen later

The problem with this game is :

The DMA is started and display switched ON in the same instruction (MOVE.L)

The 68k core write 2 words.
- First Word : DMA start
-> my vdp request the 68k bus
-> VDP_DMA_END is planfied in 536 MCLKS (this event will release cpu bus)
- Second Word : Display switched ON
-> I update my DMA
-> 0 cycles paste during DMA last update (DMA start)
-> 0 bytes transefered
-> 16 words left to transefrt / Display is ON -> 6080 cycles lefts
-> The Event will happen later (more later ...)

In conclusion, in order to emulate DMA at this degree of precision, 68k core must take in account freeze between each write ...

I think in genesis plus during the 38 cpu cycles the cpu is frozen display has already switched ON but freeze period is not increased ...

Posted: Tue Apr 07, 2009 12:53 pm
by Eke
I think in genesis plus during the 38 cpu cycles the cpu is frozen display has already switched ON but freeze period is not increased ...
I handle it as it is supposed to be:

1/ display is switched OFF
2/ DMA is executed with blanking transfer rate :68k cycle count is incremented to take DMA freezing time in account
3/ Display is switched ON

CPU cycle count is incremented BEFORE display being enabled because the VDP most probably enabled display AFTER the DMA has been processed, even if the CPU already writes the VDP register.

To put it simply, if the second write occurs before or after CPU being "frozen" does not matter, what matter is that "Display ON" occurs after CPU being "frozen".


again:
The 68k core write 2 words.
- First Word : DMA start
-> my vdp request the 68k bus
-> VDP_DMA_END is planfied in 536 MCLKS (this event will release cpu bus)
where does this value comes from ? this is actually half that value, transfer rate is in word count
- Second Word : Display switched ON
-> I update my DMA
-> 0 cycles paste during DMA last update (DMA start)
-> 0 bytes transefered
-> 16 words left to transefrt / Display is ON -> 6080 cycles lefts
-> The Event will happen later (more later ...)

In conclusion, in order to emulate DMA at this degree of precision, 68k core must take in account freeze between each write ...
and I think it's not correct: either the cpu release the bus between the two VDP writes (hum) or (more probably) the VDP does not update its internal state until DMA is finished...

there wouldn't be any interess of switching the display OFF before the DMA otherwise :wink:

Posted: Tue Apr 07, 2009 1:00 pm
by mickagame
Yes, but what i want to say is that in real hardware register 0x01 of VDP is updated (display switched ON) AFTER dma is ended (and bus released).
In emulator, the register 1 is updated at the same time the display is switched ON, because the cpu isn't frozen between the 2 words write ...

Posted: Tue Apr 07, 2009 1:09 pm
by Eke
In emulator, the register 1 is updated at the same time the display is switched ON, because the cpu isn't frozen between the 2 words write ..
no, it IS frozen
at least in genplus, I increment the cpu cycle count as soon as DMA is triggered, which is BEFORE the second write occurs

Posted: Mon Jan 04, 2010 6:00 pm
by HardWareMan
Now I have an oscilloscope too. I'd made some records of EDCLK singnal. Take a look:
Image
Image
Image
You can take full record here (use UltraScope for viewing).
Now, it's look like EDCLK more complex, than we think. So, what do you think?

Posted: Thu Jan 07, 2010 12:57 am
by tomaitheous
HardWareMan: Since you have a digital scope, you think you could take some simple pics for us? 8 Greyscale levels of RGB so see if the difference is linear in value and also the same levels in Highlight mode and shadow mode. To clear up S/H, normal once and for all? I've heard that S/H fits nicely into a 12 bit palette and that S/H just adjust the step increments. But I've also read that idea/method this doesn't display right for all games.

Posted: Thu Jan 07, 2010 7:10 am
by HardWareMan
tomaitheous wrote:HardWareMan: Since you have a digital scope, you think you could take some simple pics for us? 8 Greyscale levels of RGB so see if the difference is linear in value and also the same levels in Highlight mode and shadow mode. To clear up S/H, normal once and for all? I've heard that S/H fits nicely into a 12 bit palette and that S/H just adjust the step increments. But I've also read that idea/method this doesn't display right for all games.
You make demo, I'll take a record. OK?

Posted: Thu Jan 07, 2010 9:36 am
by TmEE co.(TM)
I made this ROM to test things, and there is one fun thing on real HW with it.
http://www.fileden.com/files/2008/4/21/ ... HLTEST.BIN
Top left is a 17 color gradient (I included shadow+black too as first col, though it probably is just black), Top right is normal. Bottom left is shadow and bottom right is highlight.

Here is how it is on my MD2 :
http://www.fileden.com/files/2008/4/21/ ... Result.jpg

Posted: Thu Jan 07, 2010 11:32 am
by HardWareMan
OK, here we go. My picture (connected thru RGB):
Image
Upper ladder:
Image
And lower ladder:
Image
This records taken directly from VDP, 1st channel (yellow) from RED and 2nd channel (cyan) from GREEN. I use "open" DC input, so all measurements are absolute. So, use this full records and see offset in Ultrascope. Is this enough for you?

Posted: Thu Jan 07, 2010 2:22 pm
by Eke
Interesting, the min/max levels in each mode are as specified in the documentation but steps are not linear. Also max value is not pure white where as 0 seems to be pure black.

What is the difference between top left and top right again ?
Strangely, in an emulator, top left is showing more gradient bars that on your pictures (as if each of the last 4 bars were splitted in two) but the oscilloscope indeed shows the intensity jumps as expected. Maybe there are some missing VDP writes on real hardware ?

Posted: Thu Jan 07, 2010 2:39 pm
by HardWareMan
Eke wrote:Strangely, in an emulator, top left is showing more gradient bars that on your pictures (as if each of the last 4 bars were splitted in two) but the oscilloscope indeed shows the intensity jumps as expected. Maybe there are some missing VDP writes on real hardware ?
No. On TV all gradients is good noticeable. Just matrix of the camera is overexposure and the black steps is disappear.

Posted: Thu Jan 07, 2010 3:34 pm
by Eke
No. On TV all gradients is good noticeable. Just matrix of the camera is overexposure and the black steps is disappear.
Hum, I'm not speaking about the black steps but the last light grey/white steps. here is the output on emulator:

Image

Also, on your oscilloscope capture, it clearly shows that the last four steps are "wider" than other steps. On the emulator, all steps have the same "width". Strange.



Regarding other VDP timings, there are still some stuff we were talking about that are left uncleared and might be interesting to figure. I will list them here for further references:

(1) some additional measure on the pixel clock in H32 mode: how many pixels are between HINT and HSYNC, between VINT and HSYNC as well as the width of back/front borders, back porch, hsync, etc (using /YS and /HSYNC)... like Jorge Nuno did in H40 mode.

(2) another thing I would like to do is to code some kind of test program that use Hcounter latch ability to figure the Hcounter value when HINT and/or VINT are triggered. A minor hardware modification would be necessary though (running a cable from /IPL2 output to /TH input on controller port 2) so I'm not sure if anyone would like to run it :roll:

(3) some other test programs I had in mind to test interrupts behavior:
(all interrupts should be masked on 68k side first)
. HINT disabled & VINT enabled on VDP side then observes /IPL2 to see how long vertical interrupt remains active.
. HINT & VINT disabled on VDP side, wait for line 225 and enable VINT then trigger on /IPL2 to see if vertical interrupt remains pending. If ok, repeat the test by delaying the wait to all lines between 225 and 224 (next frame) to see how long it remains pending.
. same tests with HINT on line 160 instead of VINT.

(4) VRAM bus signal observation

:wink:

Posted: Thu Jan 07, 2010 3:58 pm
by HardWareMan
You free to do any of hardware modification - I'll easy repeat it and I'll do all signal records. So, tell me your plan?

Posted: Thu Jan 07, 2010 4:05 pm
by Eke
HardWareMan wrote:You free to do any of hardware modification - I'll easy repeat it and I'll do all signal records. So, tell me your plan?
I will first try to write some of the test programs myself but it might take a while because I never did that before :oops:

Now, if you can sample MCLK, maybe you can do some of the video signal measures with a game using H32 mode and horizontal interrupt. Or use EDCLK as a reference (pixel clock is only output through some undocumented VDP register bits).