Author Topic: Regarding Refresh Rates  (Read 4381 times)

0 Members and 1 Guest are viewing this topic.

Offline tilt

  • Global Moderator
  • Elite Member
  • *
  • Posts: 304
  • Repair man of DKF
    • Awards
Regarding Refresh Rates
« on: August 07, 2020, 08:53:36 pm »
I've seen some confusion regarding the true refresh rate that is generated on a Donkey Kong PCB which I would love to clear up in what is ideally a concise post.  I'm hoping that this clears up some of the 60 versus 60.6060 Hz discussion that has been going on lately.

Let's begin at the analog circuitry level (From the Donkey Kong video board schematics):

This can be a bit difficult to decipher even for an experienced electrical engineer, but it's important we note the crystal oscillator X1 which is 61.44 MHz in frequency.  This is the master clock signal for which all clock signals (including the CPU clock and pixel clock) are derived from.  Beyond this, there is a mix of both filtering circuits and amplification before the signal reaches transformer T1.

The next part of the circuit is where things get more interesting (and more difficult to understand):


Reading from left to right, there is some op-amp circuitry. Think about this section as amplification and more filtering, not actually changing the clock signals yet.  These chips are labeled 10116.  1E, which is labeled 10136 is a programmable counter that is used by a divisor by 5.  1Hx4 is a series of buffers that follow this.  So as of now, our original 61.44 MHz clock signal is now 61.44 MHz/5 = 12.288 MHz.
The next part of the circuit generates the essential clock signals for the operation of the PCB:

These chips are 74LS161's, which are binary counters.  They are cascaded to divide out the clock signal further.  Note the labels (such as 1/2H) on the wires.  These are labeling different buses that go to places where these clock signals are needed.  In terms of explaining the division, I'm going to cite the MAME documentation that explains very well how the division happens:

So at this point, two important clocks have been generated, but the vertical refresh rate of the PCB has still not obviously made its appearance.  To find this, one needs to look at two numbers and consider one more important division.  In order to simplify slightly, I'm going to jump right to where this division occurs:

It's important to note for this part that the total frame is 264x384, but only 256x224 display game graphics.  What's also important to note here is that from the MAME documentation it is known that the horizontal circuit counts until 384=256+128, and the vertical circuit counts from 248 until 512 giving 264 lines.  Just to explain the relevance of these numbers a bit more to cross-check our results, 6,144,000 / 384 gives us 16,000Hz, which is the horizontal scan frequency (time it takes to draw one scan line).  16000 / 264 lines gives us 60.60Hz to compose a full frame with 264 scan lines in it and "384" pixels across. (not all pixels and lines have visible graphics, so only 256 x 224 display game graphics). These are our two integer numbers that divide out our pixel clock.  From here, one can finally calculate 60.606 Hz: 
61.44MHz/5/2 = 6,144,000 (pixel clock or 1/2H)
6,144,000/264/384 = 60.6060606... Hz

A way to go a step further from what I have already done here is to find the sections of the circuits that count until both 384 and 264, but the integer numbers are derived from the circuitry itself and the PCB certainly does not generate 60 Hz for the vertical refresh rate.

It might be worth explaining where some of the confusion comes from.


Here is an example image that outlines the confusion.  As one can see, the scan rate of the Sanyo 20EZ monitor is specified as 60 Hz, within plus or minus 5 Hz.  This is a tolerance, meaning the monitor can take any refresh rate in this range.  60.6 Hz is well within this tolerance.  What the monitor can interpret is also irrelevant to what the game board produces since they are completely separate electrically, especially in a direct feed game.

I hope this explanation cleared up some misconceptions and hopefully taught a few people something new.

Sources:
MAME source code:
https://github.com/mamedev/mame/blob/master/src/mame/includes/dkong.h

Donkey Kong Schematics:
https://www.mikesarcade.com/cgi-bin/download.pl?file=dk-tkg4u.zip

« Last Edit: August 07, 2020, 09:17:22 pm by tilt »
My stream is currently (http://www.twitch.tv/expandedidea/)
PB(s):
Donkey Kong: 1,116,400 (KS)
Donkey kong Hard roms(prev. world record): 914,200
Crazy Kong: 513,700 (KS)
Member for 10 Years DK 1.1M Point Scorer snek IGBY 2016 DKF Team Member DK 1M Point Scorer IGBY 2015 DKF Team Member CK Killscreener DK Killscreener IGBY 2014 DKF Team Member Blogger Twitch Streamer

Offline YesAffinity

  • Spring Jumper
  • *
  • Posts: 578
    • Awards
Re: Regarding Refresh Rates
« Reply #1 on: August 09, 2020, 09:51:12 am »
Great info!  How does this translate to something the Mr. Video and capturing gameplay via a s-video compatible USB capture device?

Is the 60.6hz also potentially why the video output doesn't work with a lot of non-analog devices.  For instance, I can use a supergun with my TKG-4-11 board set, and take the output to an OSSC, or take the output to a CRT monitor.  The OSSC sees a signal but it blips in and out and I never get video.  Taking that same signal from the supergun to a CRT TV, the CRT TV displays it no problem.

When I was using a jrok v4 encoder to get signal out of the game board's edge connector, some devices will work with it, some will not.
Matthew 21:22

DK Arcade PB (verified): 970,200 KS
DK Start PB (verified): 126,600
DK L1-1 PB (verified): 11,400
DK PB 1st Man: 622,000

Donkey Kong Direct Feed How-To - http://donkeykongforum.net/index.php?topic=1413.0
^Now outdated, see instead: http://donkeykongforum.net/index.php?topic=2471.0
Member for 9 Years DK Killscreener Blogger Twitch Streamer