SpritesMind.Net

screenshot from asian md2 + mega-cd 2. (mega everdrive 1)

That's nice how do you measure that ? executing long loop then calculating elapsed time ?

Yes, it's count number of cycles for 1 second, then repeat again.
for gfx processor it's repeats 128x128 conversion in a loop.

Probably explains why the CPU speed got measured a bit too slow (because some cycles are lost to refresh, even the cartridge slot gets a few, while RAM gets a lot more).

My Genesis 2/CD2/32X
PCB ver 2 NTSC CD2 2.11X U
Main - 7,559,458
Z80 - 3,584,113
Sub - 12,162,088
ASIC - 1,835,008

My Nomad
PCB ver 2
Main - 7,559,462
Z80 - 3,584,112

My CDX
PCB ver 2 BTSC CD2 2.21X U
Main - 7,559,476
Z80 - 3,584,092
Sub - 12,222,928 (more variance in this than my CD2)
ASIC - 1,835,008

It does not work on my CDX. I get a pink screen and nothing at all on it. Maybe something is happening when it goes to test the CD.

EDIT: Works fine on my CDX - the 32X I had plugged into it is getting flakey. Probably needs cleaning... again. Anywho added CDX speeds... which are pretty much the same as the others.

Just out of curiosity, how do you know the loop lasts exactly one second without counting cycles ?

I didn't check that code, but I suppose vblank is involved? That's how I did the measurement in 68kbench (check how many times the loop runs for 10 frames). You do need to account for the difference between NTSC and PAL, mind you (as well as the fact that the code will run slower if running from RAM rather than ROM).

Test goes 1 second, counter - 50 vblanks for PAL, and 60 vblanks for NTSC. Code executed from ROM.
About RAM I did not know, maybe I will do this too.

Sorry for the dumb question, but how is VBlank triggered ? I guess it's an internal clock to the VDP ?

So how is it possible this way measuring a timing problem in the VDP ?

And I guess the CPU is timed the same way. So how do we differentiate a problem with the VDP and a problem with the CPU ?

Sorry for the dumb questions, I have very little knowledge in hardware

No, those are very good questions. The engineer in me loves those sorts of questions. The short answer is that detecting problems with the clock rate of the CPU and VDP will be a tough nut to crack. The MD uses a master crystal and divides down all clocks from it, so if one clock is off, they all will probably be as well. Maybe supply an external clock to the TH line on a controller port. Say, a 100Hz signal that you've verified as accurate. Then use that as the timing signal for the program.

If I remember rightly, the MD triggers the vblank on a particular raster line, which varies for NTSC and PAL. That should be in the hardware manual.

Wouldn't the TV barf at the resulting signal if the VDP clock goes off?

And yeah, everything is fed from a single master clock but also they get divided clocks (so things run at different rates) so it's still possible for only one component to have a clock problem if the issue happens between the divider and the component.

"Ram" version:

Tested - yes, it even more slowly:

I used to tune Atari XL and C64 oscillators by looking at the color of Pitfall II on the TV, knowing what the colors SHOULD be.

It gets you close enough without needing an o-scope, but if you have an o-scope, so much the better. From the schematics in the service manuals, the MD video encoder seems to take the osc input from the MD and not a separate crystal, so you should be able to see a color shift if the MD clock was far enough off. Note that this is on old CRT TVs. Digital TVs tend to be immune to things like frequency shifts as long as they don't go too far out of spec.

Got 7,645 by code executing from a12010-a12013 (scd registers area):
also tested $200000 (sram) and $600000 (scd word-ram) - 7,525 same as rom.

Would be nice to have a version showing speed from different area :
ROM / RAM / comm registers...