SpritesMind.Net

Hi,
I'm currently thinking about a possible hardware emulation of the Genesis in a FPGA. I'm only at a stage where I want to gather as much information as possible, and I'm somewhat struggling with some hardware restrictions of the board I'm using.

So here is my question : from you experience, what would be the consequences of running the Z80 a bit faster (i.e "Main Clock"/14 instead of "Main Clock"/15) on emulation ?

Digitized sounds would be off key. Usually, they're only used for drums, but Phantasy Star 4 has some melodic samples in it, and the music would not sound right.

If you can use a normal signal as a clock input, it shouldn't be hard to use the top bit of a counter counting to 15 as a clock signal.

That depends on how the playback code is written. If it's counting Z80 cycles to time the DAC writes then you'd obviously run into problems if you overclocked the Z80. But if the code only relies on the YM2612 timers (and the VBlank IRQ) then I don't see how it should matter if the Z80 ran at a higher frequency.

The issue is not related to clock generation itself, but to resource sharing.
MCLK/15 and MCLK/7 will overlap. Using MCLK/14 and MCLK/7 clocks makes it easier to synchronize the whole stuff.
I guess I could correct this "overclocking" by inserting waitstates every 14th cycle or so.

Yes, using wait states would be a good idea.

All games I've disassembled use cycle counting to time DAC playback. I haven't heard of any games that use timers for anything but music timing.

Gigasoft wrote:Yes, using wait states would be a good idea.

All games I've disassembled use cycle counting to time DAC playback. I haven't heard of any games that use timers for anything but music timing.

I believe some does as Duke Nukem which use a slow but powerful sound driver.

Waitstates will slightly corrupt DAC samples, as the DAC relies entirely on software timing for output of data. If you've ever played a PAL C64 SID tune on NTSC by only calling the music player 5 out of every 6 frames, you may have heard this type of error. I expect the audible error to be worse when dealing with the DAC. You won't be fixing the pitch, you'll merely be inserting a slight delay which mayl manifest as a pop or crack at the point of the waitstate, depending on the exact timing of the sample writes.

No, that's not true. The wait states would happen around 255714 times per second, which is a frequency much higher than what we can hear.