Megadrive video timings

[Snake]

TmEE pointed me at this thread, and I read this:

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.

... and thought 'ah, this old argument again...' - but now I've read the rest of it.

Clearly, S/H mode does indeed basically (almost) double the number of colours, and the 'doesnt display right for all games' thing is just wrong. I tested this way back in the KGen days.

But, on my crappy old TV, through RF no less - it looked like the crossover point from normal to highlight was at 0x888 - and since that made perfect sense, that's what I did. From Hardwaremans posts its clear the crossover point is actually at 0x777. No big deal, but nice to know

TmEE - fix your program so it displays this properly on real hardware please

While I'm here:

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

Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.

[Graz]

Another thing I documented a long time ago.

Any chance that documentation is available for us to read?

[Snake]

It was all posted on a devchannel set up by (I believe) Charles Macdonald, and I don't know if it's still around. I did keep notes of a lot of this stuff but then lost it However, pretty much every emulator out there since then handles all the stuff I found.

[mickagame]

TmEE pointed me at this thread, and I read this:

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.

... and thought 'ah, this old argument again...' - but now I've read the rest of it.

Clearly, S/H mode does indeed basically (almost) double the number of colours, and the 'doesnt display right for all games' thing is just wrong. I tested this way back in the KGen days.

But, on my crappy old TV, through RF no less - it looked like the crossover point from normal to highlight was at 0x888 - and since that made perfect sense, that's what I did. From Hardwaremans posts its clear the crossover point is actually at 0x777. No big deal, but nice to know

TmEE - fix your program so it displays this properly on real hardware please

While I'm here:

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

Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.

Very interesting !!!
It could explain the special effect from mickey mania?

[Eke]

Very interesting !!!
It could explain the special effect from mickey mania?

Not really, this issue is probably more related to the way VDP is processing sprites during HBLANK: when display is disabled, sprite processing is very likely also disabled and the result is that only some of the sprites will be processed for the upcoming line (in Mickeymania, the first 5 sprites with xpos=0 are processed, you could eventually relates this to the number of clocks during which display is disabled).

The only way to know exact timings would be to spy those VRAM bus signals and see how, when and what stuff are fetched from VRAM

[tomaitheous]

TmEE pointed me at this thread, and I read this:

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.

... and thought 'ah, this old argument again...' - but now I've read the rest of it.

Clearly, S/H mode does indeed basically (almost) double the number of colours, and the 'doesnt display right for all games' thing is just wrong. I tested this way back in the KGen days.

But, on my crappy old TV, through RF no less - it looked like the crossover point from normal to highlight was at 0x888 - and since that made perfect sense, that's what I did. From Hardwaremans posts its clear the crossover point is actually at 0x777. No big deal, but nice to know

TmEE - fix your program so it displays this properly on real hardware please

While I'm here:

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

Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.

I don't remember the argument details, but something about brighter than white (which is now known doesn't exist). Not a big deal, but it's nice to know. Matters to me so I can get my colors correct for my apps though I'd still like to know what 0xEEE is really is in comparison to 0xffffff (or just 252/252/252). It would be nice to know if steps by 36 are pretty damn close, so I can keep using those

Also, on the interrupt/halt in between cycles of an instruction; are they in segments of 4 cycles or as low as 2 cycles?

[Snake]

Not a big deal, but it's nice to know.

Oh, sure, very nice But a bit different to what people have been implying to me for a long time, i.e. that the whole thing was way off.

It would be nice to know if steps by 36 are pretty damn close, so I can keep using those

From what I can tell the steps are around 34, so you're pretty close. This was done by outputting from PC to TV and adjusting till it looked right.

However be aware that if you're trying to match the colours on a TV, the NTSC or PAL encoding does, in some cases, make a HUGE difference, and certain colours can look completely different.

Also, on the interrupt/halt in between cycles of an instruction; are they in segments of 4 cycles or as low as 2 cycles?

I believe it's immediate, I.E. if you write a long in which the high word triggers a DMA, and the low word does something that'd completely break that DMA, the DMA always works as expected, and the final word is written after. Figuring out at exactly which cycle the write is performed isn't easy, but probably doesn't make any difference. At least for every possible instruction I tested it made no difference.

It's a bit naughty anyway and probably shouldn't be used

[TmEE co.(TM)]

http://www.fileden.com/files/2008/4/21/ ... madSHL.jpg

This is consistent between 4 nomads... fun part is that VDP analog stuff is same as other MD's got, only difference is ASIC which is 5700 and so far I've only seen it in Nomads... I'm not going to swap the ASICs with some MD2 though, I need a more fuxored Nomad first to do that and verify that this is ASIC not external circuit dependant.

[Snake]

This is straight from the Nomad screen? It may not have enough colour resolution. Do those things have a TV Out?

[TmEE co.(TM)]

I just tried it on TV over RGB and it looks like my MD1 and MD2...

This may have osmething to do with the LCD itself, since there's ghosting going on horizontally and vertically... I guess if I remove the top bards I get things "right" on bottom.

[Eke]

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

What game use H32 mode? Or give me demo, wich do that.

Back on this:
Nemesis's Sprite Test program can switch between both modes, it does not use interrupts though. The link is here.

Otherwise, the first demo on thatpage uses H32 mode, it should be using interrupts.

I would be curious to have measures of /YS, EDCLK, /HSYNC, IPL2 signals with MCLCK as reference in both modes

[HardWareMan]

I still don't know, how to combine previously recorded data in multitrack curve...

I made record of control bus signals of VRAM (SE0, SC, RAS1, CAS1, WE0, OE1) in last scanline interval of gradient ladder of TmEE SHLTEST. But, Ultrascope allows show only 2 signals, and we need to show 7. Maybe, I can load it as RAW sound data in multitrack sound editor? Any thoughs?

If TmEE will modify his gradient demo from 40H to 32H, it will be perfect for me.

[TmEE co.(TM)]

OK, I'll have a 32H version out shortly

Here we go :
http://www.fileden.com/files/2008/4/21/ ... TEST32.BIN

I run out of sprites and I don't know why middle is black (at least in Fusion it is)

[RetroRalph]

Yes, it is. When you write the final word to the VDP that will trigger a DMA, the 68K is *immediately* locked until the DMA completes - even if it was in the middle of a move.l instruction. Surprising, but true. Another thing I documented a long time ago.

I can confirm this (if it needed confirming). F1 World Championship does a DMA with a 32bit move, the first word starts the DMA then the second word usually updates a register. In some instances the register it updates are the length registers, meaning if you don't do the DMA before that second word comes the length will be wrong.

Since most emulators do the DMA immediately anyhow it's not really a concern. My emulator performs more like the real system in that the 68K is frozen and all other components run until the DMA is finished (with the appropriate slots). 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.

There is another issue I found with this game, it seems to do a 68K->VDP DMA with length of 0, thereby (according to docs) length is set to 0x10000. The problem is it does this every frame, which means some frames are spent doing just the DMA. Does anyone know if DMA can ever be broken out of, especially if length is set to 0? And do any games rely on length=0 actually being length=0x10000 for 68K->VDP DMAs ? My emulator has a flickering display if I do the DMA due to the way I emulate the system mentioned above, there could be bugs in it but am just wondering if there is a knowledge gap here on DMA. If I skip the DMA the display is much closer to how other emulators display it.

[Eke]

Since most emulators do the DMA immediately anyhow it's not really a concern. My emulator performs more like the real system in that the 68K is frozen and all other components run until the DMA is finished (with the appropriate slots). 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.

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.

So when DMA occurs, just add the exact number of cycles required by DMA to 68k cycle count and you are set. Afaik, no games rely on tight timings for the 'after DMA' 68k instruction occurence (i.e if it's a write that affect VDP, it always occurs in good time, for example during HBLANK), so you don't really need cycle granularity for 68k when it's "frozen" (only for VDP rendering) , as long as you properly "freeze" the CPU as soon as the writes that trigger DMA is done. Also keep in mind that VDP might have some latency when handling data/register writes from CPU and CPU bus request, so 68k cycle granularity won't give you necessarely more precision...

My emulator has a flickering display if I do the DMA due to the way I emulate the system mentioned above, there could be bugs in it but am just wondering if there is a knowledge gap here on DMA. If I skip the DMA the display is much closer to how other emulators display it.

Most game disable the display before doing DMA or do this in VBLANK/HBLANK, so you shouldn't notice any flickering. In other case, it's very unlikely the DMA is going to affect VDP RAM regions used for the current frame/line.
Also don't forget some VDP settings are latched during HBLANK, and especially Verticall Scroll RAM values that are sometime written by games DURING active line but shouldn't be taken in account until next one, I know a few games (Lotus 2 for example) that rely on this. I bet it is different when you enable 2-cell vertical scroll but those games don't use this and I'm pretty sure horizontal & vertical scroll offsets for each plane are fetched/calculated once before line rendering.