M68k instruction cycle counts

In my quest to fully understand the Genesis, I'm gathering data on the system's timing. I've already gathered the following from emulator sourcecodes and done calculations to confirm them, and they seem valid, given that the calculated framerate is right around 60Hz:

What I need now is a full list of the cycle counts taken by each instruction, in each valid addressing mode. Does anybody have anything of the sort?

 

So that would mean that a NOP, for example, would take four cycles for reading the instruction word, right? I would also assume there are no "dummy" memory accesses like on the 6502? Where, for example, even though NOP has no operand, the 6502 still reads the byte after the NOP instruction and throws it away, meaning that all instructions take at least 2 cycles.

 

More than likely not, unless what you're doing doesn't fit in one frame (and you want it to run one-framed). I want to know simply because I want to play around with hitting VDP registers on various parts of a scanline (I know you can't hit VDP RAM but you can hit the registers). I've already made jittery raster splits, but I'm worried that it might not be easily possible to get closer than 4 cycles to a stable interrupt.

What I'm asking will be more useful for democoding than anything - if your code is large enough that it doesn't run in one frame, then I doubt cycle-optimizing will help much.

 

What would help would be VDP documentation that is as detailed as this VIC-II documentation, down to the cycle level, essentially. Of course, it's much easier for the C64 as the whole system runs off one unified clock. From C= Hacking issue 10:

Code (Text):

1.   NTSC-M systems:
2.  
3.             Chip      Crystal  Dot      Processor Cycles/ Lines/
4.     Host    ID        freq/Hz  clock/Hz clock/Hz  line    frame
5.     ------  --------  -------- -------- --------- ------- ------
6.     VIC-20  6560-101  14318181  4090909   1022727      65    261
7.     C64     6567R56A  14318181  8181818   1022727      64    262
8.     C64     6567R8    14318181  8181818   1022727      65    263
9.  
10.   Later NTSC-M video chips were most probably like the 6567R8.  Note
11.   that the processor clock is a 14th of the crystal frequency on all
12.   NTSC-M systems.
13.  
14.   PAL-B systems:
15.  
16.             Chip      Crystal  Dot      Processor Cycles/ Lines/
17.     Host    ID        freq/Hz  clock/Hz clock/Hz  line    frame
18.     ------  --------  -------- -------- --------- ------- ------
19.     VIC-20  6561-101   4433618  4433618   1108405      71    312
20.     C64     6569      17734472  7881988    985248      63    312
21.  
22.   On the PAL-B VIC-20, the crystal frequency is simultaneously the dot
23.   clock, which is BTW a 4th of the crystal frequency used on the C64.
24.   On the C64, the crystal frequency is divided by 18 to generate the
25.   processor clock, which in turn is multiplied by 8 to generate the
26.   dot clock.
27.  
28.   The basic timings are the same on all 6569 revisions, and also on
29.   any later C64 and C128 video chips.  If I remember correctly, these
30.   values were the same on the C16 videochip TED as well.

I know that the Genesis isn't setup so much like the C64. I know there's the master 53MHz crystal, and that it is divided by 7 for the 68K/2612 and 15 for the Z80/PSG. I haven't got the dot clock yet, so I don't know how that ties into the VDP, and I don't know if it'll even matter that much as a practical matter. On the C64, it's mainly used to know the fact that a 1MHz cycle is 8 pixels.

 

No, just like the C64 is forever limited to 8 sprites on a scanline, I'd imagine the VDP is limited to 320 pixels of sprite data per scanline in 40 cell mode, regardless of whether or not the sprites overlap. And also, I haven't tried to reset the sprite link table mid-frame, so I'm not sure if you could do a sprite multiplexer or not.

 

That game wouldn't be Wiz 'n' Liz by Psygnosis, would it? It's intro sequence has a nice reflection effect, but I'm not sure if it uses sprites or not.

It wouldn't surprise me if it was, because Psygnosis always did have awesome code, as far as I'm aware (as well as being quite prolific on the Amiga).