1.21 gijacycles?!!?! (megadrive)
category: code [glöplog]
For our sega megadrive/genesis prod our z80 is reading about 8.8kb/s off the 68000 memory. That equates to about 1.6K cycles lost off the 68000's clock per ntsc frame do to access. I think that's a lot. Before I go looking at a 68000 manual to tediously average all the cycles I am going to ask you, pouet, how many instructions do you thing 1.6K cycles is?
also, vgm sucks
also, vgm sucks
thing = think
anything from 20 to 400 instructions, probably around 100-200 instructions
One more issue I learned the hard way: Z80 accessing the 68k bus steals way more 68k cycles on a real megadrive than in emulators. This explains some minor glitches in Overdrive final that are present in emulators but not on real hardware and vice versa.
yeah I'm experience a glitch in my production. Sometimes... not often but sometimes I frame skip. I think this is because my vblank code + my main loop + cycles stolen > frame. My code then waits for the next frame. I'm just trying to determine just how many cycles are stolen so I add everything up and prove that the glitch is exactly from this.
btw, kabuto nice work on overdrive
btw, kabuto nice work on overdrive
> For our sega megadrive/genesis prod our z80 is reading about 8.8kb/s off the 68000 memory. That equates to about 1.6K cycles lost off the 68000's clock per ntsc frame do to access.
How do you get your 1.6k cycles lost by 68k from 8.8kb/s reading speed of Z80?
How do you get your 1.6k cycles lost by 68k from 8.8kb/s reading speed of Z80?
My math could be wrong. I assumed 11 cycles per z80 access. Mask of Destiny has a logic analyzer and has counted about 8-11.
I solved my problem anyway so I'm not that interested. still kinda interesting though
I solved my problem anyway so I'm not that interested. still kinda interesting though
So what was the problem?
I think this was (5th post) the problem. Optimizing fixed it, as it should.
sigflup, ok, i've got it. ~11 68k cycles per single z80 access. 10x!