New technical analysis confirms the evidence against Billy Mitchell

Hot off the heels of the new Billy Mitchell testimony published on Friday, perfectpacman.com is proud to publish a new 48-page technical analysis by hardware engineer and Donkey Kong expert Tanner Fokkens. Fokkens is a moderator and longtime member of Donkey Kong Forum, and co-founder of Snektronix Incorporated (producer of the popular arcade direct capture device “Mr. Video”). In addition to his technical qualifications for this project, Fokkens’ research into the Billy Mitchell case goes back years before even the public score dispute at Twin Galaxies in 2018.

This independent analysis represents months of work by Fokkens and others to assess the evidence published by Jeremy Young in February 2018, demonstrating that Mitchell’s historical Donkey Kong score submission tapes were an exact match for the emulator MAME, and were not congruent with actual direct feed recordings from an original, unmodified Donkey Kong arcade machine. (Recall that, while MAME is a legal platform in high score competition, submission standards are different. Thus, MAME scores which are passed off as coming from original arcade are disqualified.)

In this new analysis, Fokkens expertly takes the existing evidence a step further, by dissecting exactly why these different transition screens appear the way they do on both the arcade and MAME platforms. This includes a line-by-line look at the graphics code within the original Donkey Kong ROM program, as well as programming instructions found in the MAME source code.

Fokkens’ analysis is reposted below, however the original document can be downloaded here: https://docs.google.com/document/d/13HRyhZNHDvWNHfVvDr432F4foWiB56Eo

The document also comes with six expert verification statements from the following qualified community members:

• John Kowalski (hardware engineer, game developer)
• Barry Rodewald (MAME developer)
• Jeremy Young (Donkey Kong Forum moderator and DK killscreener)
• David Race (Pac-Man world record holder, investigative researcher)
• Wes Copeland (Former Donkey Kong world record holder)
• Carlos Pineiro (Arcade technical expert, former tech for Billy Mitchell)

This independent analysis is likely to play a significant factor in the ongoing legal battle between Mitchell and Twin Galaxies. While Mitchell continues to rely on witness statements from his friends (such as Todd Rogers), the technical evidence proving Mitchell’s tapes could not have been produced as he has always claimed keeps piling up. Mitchell’s defamation lawsuit against TG, and TG’s counter-suit against Mitchell and Walter Day for fraud, are both headed to a trial tentatively scheduled for March of next year. You can keep up on all the latest on this case right here at perfectpacman.com.

---

Comprehensive Analysis and Case Study of Donkey Kong MAME and Arcade Video Output

Tanner Fokkens

Version 1.0

Published: September 6, 2022

---

In Memory of J.C. Harrist and Benjamin Smith (Apollo Legend)

---

Table of Contents

Background and Motivation

Orientation and 240p video Explanation
IIa. Brief CRT (Cathode Ray Tube) Explanation
IIb. RGB Video Explanation
IIc. Orientation

Donkey Kong Arcade Hardware Transitions
IIIa. Arcade Donkey Kong Transition Definition
IIIb. How Transitions are Drawn on Donkey Kong Hardware

MAME 0.115 and Below Donkey Kong Transitions

MAME versus Arcade Transition Comparison

Discussion and Conclusion

Appendix
VIIa. Flipped Orientation Effects on the Transition
VIIb. Billy Mitchell 1,047,200 2006 MTV Announcement Video
VIIc. Rolling Shutter Effect
VIId. High Speed Camera Recording of the Barrel Transition
VIIe. VGA to Composite to VCR Recording
VIIf. RGB to NTSC Converter Device

References

About the author

Expert Verification and Peer Review
Xa. John Kowalski Expert Verification Statement
Xb. Barry Rodewald Expert Verification Statement
Xc. Jeremy Young Expert Verification Statement
Xd. David Race Expert Verification Statement
Xe. Wes Copeland Expert Verification Statement
Xf. Carlos Pineiro Expert Verification Statement

---

I. Background and Motivation

In the early 1980s, video arcade games were ever-present in the minds of children, teenagers, and adults alike. As early as the year 1980, 86 percent of the US population between 13 and 20 had at least played a video arcade game [1]. This rapid expansion of interest in video games led many teenagers and young adults to shift away from traditional sports as a competitive outlet, and over to dedicating their free time to mastering these new forms of digital entertainment.

Beginning in 1980, large-scale video game tournaments began to be held, with one of the first being the Space Invaders Championship, hosted by Atari [2]. From here, organizations and teams were founded for the proliferation of interest into the playing of arcade games at a competitive level. One of these was Twin Galaxies, which was founded by Walter Day in 1981 in Ottumwa, Iowa [3]. Walter Day’s iteration of Twin Galaxies allowed players to compete head-to-head for a chance at getting their high score achievements recognized in the Guinness Book of World Records. This was a seminal moment for the beginning of eSports, which has grown far larger than what could have ever been imagined in the early 80’s [4].

Almost 40 years on from this point, new generations of players have picked up the hobby of what is now called “Classic Arcade Gaming”. As was done in the past, players today still compete head-to-head through online tournaments for notoriety in the community. However, instead of tournaments being exclusively held in-person on now-vintage arcade machines, many players choose to use an emulator called MAME to play these games. Some sites, such as DonkeyKongForum.net, choose to compile MAME and arcade scores into a single scoreboard. Others, like the modern Twin Galaxies, separate MAME and arcade scores into two different scoreboards. Regardless, whether these scores are separated or intermingled, the platform that the score was achieved on is specified [5].

Prior to the last 20 years, scores were not often recorded in full (digitally or on VHS). Before these times, scores had to be verified by a referee, or simply through a photograph of the score on the screen [6]. With these older scores, it is unlikely that there is any question whether the score was achieved on arcade or emulator, due to the MAME emulator not being well-developed until about 2000 [7]. However, after MAME came to a sufficient point of maturity, a problem arose: a MAME recording could be passed off as a “direct-feed” arcade recording. A direct-feed arcade recording is one where the video output of the arcade machine motherboard is directly sent to a video capture device, in contrast to simply pointing a camera at the monitor. Figure 1 below shows a comparison between the video output of direct-feed arcade versus a screen capture of MAME (from a modern computer) from the arcade game Donkey Kong, demonstrating how similar the images look.

As mentioned, legitimately recognized scores are set on both the MAME and arcade platforms. If this is the case, one may think that there is little issue with passing off a MAME score as arcade. However, as will be explained in detail below, this assumption would greatly put the integrity of the scoreboard at risk of showing falsified scores.

When a MAME score is submitted to the Donkey Kong Forum or Twin Galaxies scoreboards, the most important evidence for the submission is the MAME input file, also known as an “INP” file. This digital file, which records the player’s inputs, allows for a score to be played back on the MAME emulator, showing the gameplay that the player executed during their performance. One important distinction with officially recognized INP files is that they must originate from a special version of MAME known as WolfMAME. In the non-WolfMAME version of MAME, it is easy to create a spliced-together INP file that would not show any obvious signs of tampering when the file is evaluated for legitimacy on the MAME emulator. Thus, for competitive submissions, it is required that WolfMAME be used [8]. In WolfMAME, cheats are removed, the use of savestates for splicing INP files is removed, and the game settings, which are controlled by dual in-line package (DIP) switches on a real arcade machine, are fixed to a set value [9].

Even with all these precautions, some people have still managed to create spliced-together input files. In 2016, a player named Jose Ramis was permanently banned from the scoreboards for MAME Action Replay (MARP) and Twin Galaxies for using virtual machine software to create a seamless INP file that would play back in WolfMAME [10]. Ultimately, his attempts at cheating failed due to the strong analysis methods employed by MARP referees for detecting cheating in WolfMAME INP files. It is important to note that the cheating methods used by Jose Ramis were only detected due to the presence of an INP file. The playback speed variation from his Galaga submission is shown in Figure 2.

If the playback of this cheated INP file was recorded by video capture software and subsequently passed off as arcade, there would be no way of knowing the methods that were used to cheat. Only INP file analysis could have revealed the playback speed variation. Demonstrably, it is very important to ensure that an arcade performance has been played on real arcade hardware, where splicing (outside of obvious video editing), is not possible.

For both direct-feed and camera recordings of the arcade gameplay, a board and control panel verification is required by Donkey Kong Forum and Twin Galaxies [11]. In this verification, the arcade hardware (motherboard and underside of the control panel) is shown to verify that the hardware is untampered with. For many games, these types of rules are recent. Higher scrutiny in arcade Donkey Kong scores only came after about 2008 [12]. Before this, hardware verification was not a required step for the submission to Guinness or Twin Galaxies. Due to this fact, there are some scores before this date that were performed when MAME existed, and hardware verification was not a required step.

For these certain scores, such as Billy Mitchell’s contested 1,047,200 and 1,050,200 tapes, video evidence is all that exists for examining if a score was truly performed on arcade hardware. In this document, arcade Donkey Kong is analyzed for the differences between MAME and arcade gameplay. Additionally, these findings are applied to Billy Mitchell’s scores in the second part of the paper to evaluate them for MAME signatures. It is imperative to recognize the differences in video rendering between these two platforms to prevent illegitimate achievements from being accepted on a scoreboard, hurting the credibility of the scoreboard and its controlling organization.

II. Orientation and 240p video Explanation

IIa. Brief CRT (Cathode Ray Tube) Explanation

Even though the video signal from an arcade machine can be captured and displayed on any monitor or computer today, the original video signal was designed with CRT monitors in mind. CRT monitors were the technology used in every television prior to the advent of flat screen technology. It is important to understand how CRT monitors operate before grasping how RGB video signals are output by arcade machine boards.

In vintage arcade monitors, three electron beams (negative charges) are generated at the back of the tube by a heated cathode. These electron beams are then attracted at high velocities to the front of the monitor due to the anode, which contains a large positive charge (usually 10,000+ volts) [13]. Left unabated, these beams collide with the phosphor layer, which illuminates when struck with charges at the front of the CRT and makes a bright white dot at the center of the monitor. However, the motion of these electrons is influenced by nearby magnetic fields, allowing dots to appear anywhere on the screen. In technical terms, the deflection force on the beam is given by the cross-product of the beam velocity and the magnetic field strength, which is defined by the Lorentz Force equation:

F=qv x B,
where q is charge, v is charge velocity, and B is the magnetic field strength

Utilizing this principle, vintage arcade monitors include a large coil, or “yoke”, that is used for deflecting the electron beam. The yoke is used to steer the electron beam as it scans across the screen, drawing the image. The input video signal to the monitor is processed to deflect, “slow down”, and “speed up” this beam as it scans across the screen. This modulation of the speed of the electrons impacting the screen is controlled by the control grids within the monitor tube. The “slowing down” and “speeding up” of the electron beam manipulates the brightness at the location of each phosphor on the front of the monitor tube by adjusting the velocity that the beam impacts the phosphors.

IIb. RGB Video Explanation

Most arcade machines, including Donkey Kong, utilize raster monitors. Raster monitors use four different signals to represent the video signal on the screen. These four signals are red, blue, and green color signals, as well as a sync signal. These signals are shown in Figure 3:

First, the purpose of sync must be understood. From [13], even when there is no input video signal or image to the monitor, the deflection coil constantly scans the electron beams for red, green, and blue left to right, line-by-line, until the bottom of the screen is reached. At this point, the beam repeats the scanning process. To know when the start of each frame is, the video signal contains two distinct pulses of a well-defined width and spacing in the time domain: a horizontal sync pulse and a vertical sync pulse. For Donkey Kong’s progressive scan video, the total resolution contains 264 horizontal lines, but only 224 of these lines display game graphics [14]. Additionally, the vertical refresh rate is 60.60606 Hz for Donkey Kong [15], which designates how many times per second that the beam scans from the top to the bottom of the screen.

For the monitor to lock on to the incoming video signal, it must catch these horizontal and vertical sync pulses, so the video begins displaying at the start of when the beam begins scanning again at the top of the monitor. Without this timing, if the input video were to be sent out of sync with where the beam is scanning, the resulting video on the screen would be jumbled and it would never recover.
The important takeaway from this section is that the Donkey Kong PCB is always scanning in video left-to-right, and then down a line at the conclusion of each line’s scanning process. This video will be interpreted the same whether the output device is a CRT monitor or digital capture device. Figure 4 is a visualization of this scanning process. In Figure 5, the scanning can be seen on an actual monitor using a high-speed camera.

IIc. Orientation

Due to this scanning mechanism and RGB video standard itself, the output video from a 240p arcade game will always draw in the same orientation, assuming the input video hardware and software are unmodified, and the screen data is read in the same order from memory. This observation is significant for Donkey Kong gameplay footage in that it is a clear marker for edited gameplay or gameplay that is generated on modified hardware. Notably, MAME did not correct for its wrong image orientation until version 0.196 in 2018 [17], so all versions prior to that leave this marker in the recording.

Video from an unmodified Donkey Kong arcade machine board displays as shown in the left side of Figure 6. The television is sideways because Donkey Kong’s monitor is positioned in a vertical orientation in the arcade cabinet. When compared to output from non-original hardware or an edited video tape (such as Billy Mitchell’s 1,047,200, also shown in Figure 6), the difference is clear.

The visible difference between the video outputs in Figure 6 clearly demonstrates a discrepancy between the video hardware in these two capture setups. As mentioned in the first section, the order the video data is scanned into the output video device does not change without changing the order of the data that is leaving the arcade board. Two analog CRT monitors are the most effective way to demonstrate this point to avoid any confusion that results from digital capture solutions.

In Donkey Kong, there are ways to flip the monitor orientation through the game itself. One example that would be known to someone who has played a cocktail cabinet. In figure 7, a two-player game being played in cocktail mode is shown.

However, this kind of argument for an incorrect orientation can quickly be debunked. Arcade games such as these include a series of DIP switches to control various game factors, such as the cost to play and the number of lives given [18]. For the game to display in cocktail mode, these dip switches must have switch H set to off [19]. This issue would easily be spotted in the game verification, and certainly would be identified by any experienced individuals onsite to verify the legitimacy of a game.

Additionally, the orientation is only flipped when player two is playing the game, to the other side of the table shown in figure 7. This problem would immediately be observed due to the presence of the second player’s score on the screen being the score in-play. This issue is not observed in the gameplay in Figure 6, which indicates a deeper issue as to why the orientation is different.

III. Donkey Kong Arcade Hardware Transitions

In this section, the concept of transitions between screens and how they are composed on arcade Donkey Kong is introduced. The information described in this section is essential for identifying whether suspect gameplay created on an emulation platform has been passed off fraudulently as real arcade hardware. These transitions are like a fingerprint of the platform the game was played on.

IIIa. Arcade Donkey Kong Transition Definition

Before explaining the transition mechanism and expected video output, the definition of the transition itself must first be understood. Donkey Kong includes four types of stages, each with a unique transition. However, the barrel transition is sufficient to examine for evidence of non-arcade hardware.

In figure 8, the How High Can You Get? screen is seen. This is the image that is displayed right before the graphics are drawn that make up the barrel stage.

Next, the process of the transition drawing begins. In a total of three frames, all the girders and ladders are drawn onto the screen. These three frames for arcade hardware are shown below in Figure 9. Notably, these images are at the end of each frame during the transition drawing cycle.

IIIb. How Transitions are Drawn on Donkey Kong Hardware

On original Donkey Kong hardware, the central processing unit (CPU) and video circuitry are separated into two boards: the CPU board and the video board. The CPU board, which contains the Z80 CPU, controls functions such as how the score is kept, what level the game is on, and the number of lives. All the game logic is stored on erasable programmable read-only memory (EPROMS) and written in Z80 assembly language. Additionally, the board contains random access memory (RAM) that stores ephemeral data, like a character’s position or the player’s current score.

The video board also contains EPROMs, but the data contained in them is different from the CPU board. For instance, the sprite ROMs on the board contains information about how the fireballs or Jumpman will look on the screen. In Figure 10, the Donkey Kong PCB board stack is seen.

In the next few paragraphs, the ROM disassembly for Donkey Kong is referenced for insight on how graphics are filled into VRAM [20]. When it is time for the barrel stage to be drawn on the screen, the game code instructs the Z80 to load the DE register (data saved within the CPU) with the address #3AE4, which is a location in the CPU ROM that designates the start of the girder drawing data table. This is shown in Figure 11.

Next, the code at #0CDC jumps to another location that ends up at the start of the girder drawing routine. There are additional routines for ladder drawing, but we’ll focus on the girder routines. The code block in Figure 11 executes repeatedly to populate register HL with the location in video RAM (VRAM) where the girder drawing data table from the ROM will be written to. This subroutine is shown in Figure 12.

The subroutine starts by loading register A with register DE, which was loaded with the memory location at the start of the table. Throughout the subroutine, the value of DE is incremented, which acts as a pointer that is used to load the next element of the girder drawing instructions from the ROM into VRAM. Line #0DB7 jumps to a routine which converts HL to the VRAM address where the girder data will be drawn. Additionally, the table data itself is constantly being passed off from registers A and DE into RAM locations like #63B0, due to the Z80 processor’s limited registers. The table data located at #3AE4 for the girder stage is seen below in Figure 13.

These drawing instructions reveal in what order the VRAM is filled up, as the subroutine in Figure 12 points to each VRAM location. Of the five hexadecimal bytes in each line, the first represents the object type. (06 is a given character, 05 is the girder style used on the game’s “rivet” screen, 03 is a conveyor, 02 is a girder as seen on the “barrel” screen, 01 is a broken ladder, and 00 is a complete ladder. Note that since Figure 13 represents the game drawing the barrel board, only objects 00, 01, and 02 are seen.) Bytes 2 and 3 give the X/Y location for the start of the drawing, and bytes 4 and 5 give the ending X/Y location for the drawing. Thus, seeing this data sequentially, it is concretely known what order the VRAM fills up with data. This is important for modeling this behavior.

Finally, after a location in CPU RAM has been filled with the value of the table, this value can finally be written to the location of VRAM that was stored in HL. This code is seen in Figure 14.

However, this video memory does not fill up with the newly drawn frame instantly. Due to the CPU having to run through this loop of filling up the video memory byte by byte, it takes multiple frames for the VRAM to populate. Most importantly, the CPU and video hardware cannot access the memory at the same time, so the CPU must execute all writing functionality to the VRAM during the time of the H blank, which occurs at the time of the H sync pulse shown in Figure 4. In Donkey Kong hardware, video hardware is given VRAM priority by default for access. Regular CPU RAM and ROM don’t have these restrictions, so other tasks are able to execute in the meantime between scanlines. As a result, the H sync pulse acts as an interrupt of sorts where the CPU can run through a loop of the VRAM filling during the video blanking period. In essence, the CPU waits around for the video hardware to finish accessing the VRAM before it can write girder data to VRAM.

To demonstrate how the filling of the VRAM and RAM scanning mechanism interact together to create the arcade hardware transitions, a helpful animated GIF is provided. In Figure 15, the progression of the scanning bar (seen as a pink bar, scanning left to right) is seen in relation to the contents of the arcade VRAM, seen on the left. The bar is also scanning from bottom to top during each scanline, but this process is occurring very quickly. As the pink bar scans, the VRAM contents are filled with the data from the video ROM. To the right of the VRAM, the output on the screen is seen from this process.

From this figure, all the transitions in Figure 9 can be identified at the point at which the pink bar reached the end of the screen. Additionally, the order in which VRAM is populated has been verified through the code itself, and the scanning mechanism’s root cause has been identified through the known mechanism of how raster video is generated. It can be understood that anything that is in VRAM at any given time is available for the video hardware to scan it onto the screen at the refresh rate timings.

Additionally, it is very pertinent to say that any variation from this scanning/filling of VRAM on arcade hardware requires software or hardware modification. From Figure 15, only two factors are relevant to the drawing of transitions, which is the rate VRAM is filled and the rate the video hardware scans the memory for changes. Changes to this scanning mechanism are infeasible without massive hardware modifications, as no vintage monitor would ever tolerate the timing changes in the scanning process. For instance, the Sanyo monitor in the Donkey Kong machine will tolerate 500 Hz of variation from the horizontal sync frequency of 15.75 kHz, and 5 Hz of variation from the vertical sync frequency of 60 Hz before desyncing [21]. For the player, such large changes would manifest in what would look like random or un-synced output on the screen, due to RGB color data being misplaced on the screen from lack of sync. The kind of changes required, like adding a framebuffer to the video hardware, could never result from aging or failing components. For the VRAM contents, the drawing order is clearly given in Figure 13. The only way for the transitions to change from a software sense would be to change this data order. This process requires modification of the game ROMs, which violates competitive rules.

MAME 0.115 and Below Donkey Kong Transitions

To spot the difference between legitimate transitions from arcade hardware and those from non-arcade hardware, it is important to understand the transitions from MAME, which is the most used software for emulating Donkey Kong.

MAME, which was first developed in 1997, is a hardware emulator that emulates thousands of different games by representing the physical components and integrated circuits (ICs) as a computer program. In MAME, the ROMs that are present on a real arcade machine have been “dumped”, which is the process of reading the contents of the original chips and copying them to binary computer files that the emulator can interact with. Therefore, all software behavior that was described in the previous section still holds true for MAME.

However, as mentioned, MAME is a hardware emulator. Hardware emulation approximates the original system, and many chips on old computers and arcade boards are not well documented [22]. The early development of MAME simulated, by closest approximation, the behavior of the target hardware, rather than the physical transistor connections (hardware accuracy) within the individual ICs themselves, or how long the execution of each instruction should take (cycle accuracy).

To understand the scanning of the VRAM in MAME, the source code can be directly referenced for MAME 0.115, which is the version before MAME updated the refresh rate to 60.6 Hz from 60 Hz [23]. For MAME, all machines are dictated by the common MAME video and CPU drivers. This can be thought of as the engine for MAME. In tilemap.c, the procedure for writing VRAM to the tilemap is described. This is shown in Figure 16.

The tilemap in MAME is generally used for updating non-sprite graphics. In Donkey Kong, sprite drawing is handled by the draw_sprite function, which is unrelated to the transitions. Figure 17 describes that the VRAM is constantly being scanned for changes at a rate much faster than the game CPU clock. In fact, once a change appears in VRAM, it instantly appears in the tilemap by being marked as “dirty”, or in need of being updated. From here, examination of the file video/dkong.c shows how the video driver for Donkey Kong is handled, with the procedure in Figure 16 in mind. In Figure 17, the write handler for VRAM is shown from video/dkong.c.

In this function (which is part of one of the macros in MAME), an if statement checks if the stored VRAM at a certain offset has a different value than the incoming data. If this is the case, the VRAM is set to this new data value, and the tile that corresponds to this VRAM offset is set as dirty (in need of being updated). In the next part of the video driver, after the video has been fully initialized, the entire tilemap is drawn at once. This code is seen in Figure 18.

This VIDEO_UPDATE function is called once per frame, or 1/60 seconds in MAME 0.115. Therefore, since the tilemap is constantly filled with the latest updated VRAM at the frame update time, it is obvious that the scanning behavior that is seen in arcade Donkey Kong is simply not present in MAME. The scanning was replaced by an instantaneous snapshot of the VRAM state.

From this analysis, you can see that MAME 0.115 utilizes a framebuffer mechanism for the scanning of the VRAM. This kind of scanning behavior is acceptable for MAME as the program does not need to match the refresh rate of the user’s monitor. The MAME window is rendered within a window on the player’s computer, which is likely to not be running at 60 Hz at all.

This behavior can be seen in the animations below in Figure 19, which demonstrate the video output of MAME versus the VRAM content and framebuffer, as well as the previously shown arcade VRAM scanning mechanism.

Just as with the arcade animations, the flashing pink screen represents the reading of VRAM (as seen on the left) to the screen (as seen on the right). As mentioned, and shown in the MAME source code, this process happens instantaneously, which is impossible on arcade hardware due to the monitor requiring sequential, scanned-in video. From this analysis, there are obvious differences between the transitions of MAME and arcade. In section V, these differences are examined in depth.

V. MAME versus Arcade Transition Comparison

For this section, arcade and MAME transitions are compared directly to better visualize the differences. Below in Figure 20, the first rendered transition frame is shown for MAME 0.115 next to a frame from unmodified arcade hardware.

The difference between these two frames is overtly clear. In the example on the left, three girders are rendered by the end of the first frame, whereas in the example on the right, the first frame shows five girders are rendered along the right side. This behavior was predicted and documented from the analysis of the MAME source code in the previous section, as well as the analysis of the Donkey Kong source code VRAM writing process. In the example on the right, five girders are drawn by the end of the first frame. Since the arcade has no framebuffer, these differences are expected. It is impossible for arcade transitions to look like the frame on the left without software or hardware modification.

Using the information analyzed in this paper, games that have been suspected of not being played on unmodified hardware can be compared to both MAME and arcade transitions. One heavily scrutinized game of this kind is Billy Mitchell’s 1,050,200 score from 2007. Prior to MAME 0.116, MAME’s rendering of Donkey Kong transitions had been consistent since 2001. Thus, MAME 0.115 is used for the following tests. In Figure 21, the comparison between MAME, Arcade, and Billy Mitchell’s 1,050,200 tape is seen.

From this image, the first frame of the transitions in Billy Mitchell’s tape visually does not match the arcade transitions. However, MAME 0.115 and Mitchell’s tape have a small, but important difference. At the end of the girder on the two tapes, there is a partially drawn girder that is entirely drawn on MAME 0.115. This variation may seem small, but it is significant. In versions of MAME past 0.115, this partially drawn girder can be seen. However, these versions of MAME did not exist when Mitchell’s 1,047,200 was made, and 0.116 was released just one month before the 1,050,200 tape.

In MAME 0.116u3, the vsync frequency of Donkey Kong hardware was changed to 60.606061 Hz [24], as this is more accurate to the real arcade machine. However, prior versions of MAME ran Donkey Kong at 60 Hz. Therefore, by using the MAME option to change the refresh rate on the older MAME version to 60.6 Hz, the partially drawn girder was visible. Alternatively, the CPU speed can also be set to 99% through cheats, which accomplishes the same effect. Figure 22 shows this setting in the user interface (UI) of MAME, and Figure 23 shows the comparison of the transitions again using the adjusted refresh rate (along with a frame from Mitchell’s 1,047,200 tape).

In the figure above, Mitchell’s tapes and MAME 0.115 with a 60.6 Hz refresh rate are identical. From this analysis, it is proven that Mitchell’s 1,047,200 and 1,050,200 tapes were generated using a version of MAME’s source code from 2001 to 2007 with the refresh rate set to 60.6 Hz. It is demonstrably impossible for unmodified hardware to show the first, second, and third transitions in Figure 23. Only the five-girder pattern shows for unmodified hardware.

VI. Discussion and Conclusion

From the above technical analysis, unmodified Donkey Kong arcade hardware cannot produce the three-girder pattern in the first frame of the barrel transition. Not only this, but it is also evident that the transition acts as a fingerprint that indicates the hardware or software that was used to play the game. In the case of Billy Mitchell’s 1,050,200 and 1,047,200 direct feed submissions, evidence in this paper supports the claim that these tapes, which were historically used by Twin Galaxies to verify the scores and record them in the database as original unmodified arcade gameplay, are not from original unmodified arcade hardware. Additionally, based on the refresh rate findings and correlation with specific MAME transitions, the gameplay can be pinpointed as being of MAME 0.115 or below’s source code, with the refresh rate set to 60.6 Hz or 99% CPU cheat setting.

Throughout this paper, it is repeatedly stated that the tapes show MAME gameplay. However, one could argue that the tapes simply show emulator gameplay, but perhaps not a version of MAME. The reason MAME was given as the definite emulation platform in this paper is because during the creation of these tapes (2004-2007), there were no other developed emulators for arcade Donkey Kong [25]. Therefore, MAME was the only option for non-arcade hardware for playing Donkey Kong at that time. It is possible, however, that MAME source code was taken and repackaged as an entirely different emulator or system. Thus, the distinction is made that the tapes are specifically derived from MAME 0.115 or below’s source code. This includes devices like the 60-in-1 board that use MAME’s source code for emulation.

The reason for the refresh rate being set to 60.6 Hz is left to speculation. One possible explanation is that whoever produced the tape wanted to ensure that the timing was accurate to that of arcade gameplay to avoid detection. MAME is known to run at a refresh rate of 60.60606 Hz. (MAMEdev, the development team behind MAME updates, made this same decision with 0.116u3.) However, this is impossible to verify without the individuals involved in the production of these tapes explaining their motivations.

Given that the irregularities in Mitchell’s tapes remained undetected from 2004 until 2018, one may ask why the supposed eyewitnesses to these games could not spot the problems in the gameplay. However, it should be remembered that these frames only last for one 60th of a second. Quite simply, the shortest interval of time humans can recognize is 13 ms [26] (which is very close to the 16.6 ms frame time), and the tapes were not publicly available until 2016 [27]. Additionally, the layman would not have the prerequisite knowledge to even know what MAME or arcade transitions look like. For these reasons, eyewitnesses are not a valid source of information to determine whether the output on the screen was from MAME or an arcade board.

One real-world example of eyewitnesses being unreliable for spotting cheating is the case of Ben Johnson’s 100-meter dash in the 1988 Summer Olympics, for which he was temporarily awarded the gold medal [28]. Every person at the Olympics in Seoul, South Korea may have seen Johnson run the race, but it was impossible for the general public to know that he had used anabolic steroids prior to the event, which were detected in his blood. For the case of Donkey Kong scores, the transitions are equivalent to the drug test that stripped Johnson of his medals.

Using the knowledge in this investigation, any future gameplay that is submitted under suspicious circumstances can be evaluated using the rationale in this document, and the adjudication body will be secure in the fact that their conclusion is backed by physical concepts.

VII. Appendix

VIIa. Flipped Orientation Effects on the Transition

As mentioned in section IIb on orientation, it is possible to flip the orientation of the video by hardware methods, relative to the default position, through changing the game to cocktail mode and playing the game in player two mode. When hardware register $7D82 is set to 1 from the DIP switches and player two mode is enabled, the video hardware reads the VRAM starting at the end and works its way back to the beginning. This is like reading a book from the last page to the first, where the book is the VRAM contents. As a result, the contents are output upside down on the screen. However, as described in previous sections, the monitor always scans this reversed memory onto the screen in the same way that was shown in Figure 4. Thus, the transitions are affected by this change as the scanning direction and VRAM filling did not reverse together.

Therefore, in Figure 24, the resulting first frame of the transition from a flipped orientation on arcade is seen next to the standard orientation transition.

From this figure, these two transitions are completely different, ignoring the obvious extra player scores in the example on the left. Additionally, even if the orientation were changed through the failure or removal of a transistor in the video circuitry. The above transitions still do not look like the transitions in either of Billy Mitchell’s gameplay tapes.

VIIb. Billy Mitchell 1,047,200 2006 MTV Announcement Video

An MTV interview with former Twin Galaxies referee Robert Mruczek was conducted in February 2006 entitled “Smashing Apart the Donkey Kong World Record” [29]. This video shows a short segment with Mruczek explaining the context of Billy Mitchell’s 1,047,200 tape submission while the tape plays in the background. This footage is significant in that it was recorded within a month after the score was verified on Twin Galaxies [30], thus, it is a good historical time capsule to rule out any changes to the tapes that may have occurred since 2006. In Figure 25, a frame from this footage is shown.

As can be seen from the frame in Figure 25, the three-girder pattern common to MAME is still visible, as was shown in the direct feed tapes. Additionally, the orientation of the television is still abnormal from the expectations for arcade gameplay. This historical video is clear cut evidence that Billy Mitchell’s tapes have always shown MAME signatures in the transitions.

VIIc. Rolling Shutter Effect

This point where the end of the screen is reached is designated as the end of the frame, but it is possible to capture the sum of two frames together from the video hardware if the capture device is an external camera. This can create confusion in that it seems that the video hardware is inconsistent in the output of the transitions, but this is not due to the hardware itself. In Figure 26, an example of this composition occurs due to camera frame rate being out of sync with the video output seen, where the frame from Figure 8, and frames 1 and 2 from Figure 9 are all summed together.

Regardless, even in figure 26, three predicted frames can all be identified. Therefore, this output could still be properly verified as arcade hardware. This kind of behavior, known as the “rolling shutter” effect, is the result of the camera’s shutter scanning across the sensor of the camera, which does not open and close instantaneously [31]. This can be a mechanical or electronic effect. More specifically, the camera sensor is being exposed to the light from multiple frames of video from the monitor at once. This behavior is not observed in direct capture games, only those captured with an external camera. For a direct capture game capture at 60 frames per second (FPS), the capture device locks onto vertical and horizontal sync pulses, so partial frames are not possible.

VIId. High Speed Camera Recording of the Barrel Transition

Using a high-speed camera running at 960 FPS, it is possible to record and verify the scanning mechanism that was described, and then modeled in Figure 15. Through this recording, the existence of the VRAM scanning mechanism was physically confirmed. In Figure 27, the result of recording the transition at 960 FPS is seen, where the left screen is the default orientation, and the right screen is the player-two, cocktail orientation.

Figure 27: The scanning of VRAM into the graphics on the screen, as shown on the monitor for standard orientation (left), and cocktail orientation (right). Recorded at 960 FPS.

From Figure 27, the scanning bar is obviously larger than what is seen in animation in Figure 15. This is because the camera frame rate is not fast enough to capture a single scanline as it traverses the screen, so multiple scan lines of the electron beam are being integrated into the bright moving block when the camera shutter is open. To capture a single scan line beam of light, the camera would have to have a framerate of 16,000 FPS, which is the horizontal refresh rate of the monitor.

Using the camera FPS and the number of horizontal lines, the thickness of the scanning bar can be calculated in terms of scanlines below.

264 Lines / (960 Frames/second / 60.6060606 Hz) = ~16 scanlines

The reason the screen is dark shortly after the beam scans an area is because the phosphor in the screen of the monitor does not stay lit up for a long period of time. That is why the frame must continuously be scanned fast enough that the darkening of the monitor due to the phosphor dimming is not noticeable to the human eye. Additionally, the reason the scanning bar in the figure on the right appears to be scanning in the opposite direction is because the camera was flipped as well to compensate for the upside down video. In reality, both beams are scanning in the same direction, relative to the bottom of the monitor.

This footage confirms the scanning behavior in Figure 15 is present on unmodified arcade hardware without question, as well as the transition variation from a flipped orientation.

VIIe. VGA to Composite to VCR Recording

If Billy Mitchell’s scores were recorded on a computer, they had to be converted from 31 kHz, Video Graphics Array (VGA) video to 15 kHz, National Television System Committee (NTSC) video for recording on a VCR. This either happened within the computer, or externally using a converter. To verify this, MAME video from MAME 0.85 (which shows the same transitions as MAME 0.115) running at 60.6 Hz was output to a VCR using the following setup in Figure 28.

Due to the frame rate discrepancies between the computer and the MAME output, there are often many transition frames that do not look exactly like those shown in Figure 20. In Figure 29, a comparison between a transition in Billy Mitchell’s 1,047,200 tape and a transition from the setup shown in Figure 28 are shown below.

From this section, another feature of Mitchell’s tapes has been confirmed: they were recorded on a computer with significant tearing due to vertical sync (Vsync) issues. These abnormal transitions are due to screen tearing, which occurs due to a mismatch between the computer refresh rate and MAME’s refresh rate. Vsync settings correct for issues like this by having MAME wait until the monitor has completed its refresh cycle before updating its frame [32][33], however, MAME’s “-waitvsync” setting is disabled by default. Thus, the screen tearing manifests in the transition as multiple frames being combined, like what was seen from the rolling shutter example (Albeit for a much different reason).

Additionally, these two transition frames would never be seen on arcade direct feed video. Figure 29 is yet another fingerprint from Billy Mitchell’s tapes that prove they were not recorded on arcade hardware, but rather a computer running MAME. Screen tearing is an artifact that directly originates from refresh rate discrepancies between the monitor refresh rate and the game’s refresh rate. Thus, it cannot originate from unmodified Donkey Kong hardware because there is only a single vertical refresh rate present on Donkey Kong hardware, which is 60.60606 Hz. This finding proves unequivocally that Billy Mitchell’s tapes were recorded on MAME with significant Vsync issues.

VIIf. RGB to NTSC Converter Device

When recording his tapes, it is claimed that Billy Mitchell utilized an RGB to NTSC converter designed in 1996 by a company called “Two-Bit Score”. This converter is shown below in Figure 30 on the left, with the receipt for the purchase on the right. The receipt and converter information was provided during the onset of the Billy Mitchell score dispute by Robert Childs.

This device utilizes some passive components (like resistors and capacitors), a crystal oscillator, and an RGB to NTSC encoder IC. This IC is most likely an BH7236 or similar variant [34]. This conclusion is reached given that the chip seen in the photo has the same pin count as the BH7236, and pins 2, 3, and 4 all go to the RGB bypass capacitors (which is also seen in the application circuit for the BH7236). The exact IC cannot be verified because the information on top has been grinded off to obfuscate the functionality of the board.

Mr. Video, which the writer of this paper designed, utilizes a similar IC for its operation (AD725) [35]. For all the direct feed arcade footage in this paper, Mr. Video was utilized for conversion of arcade RGB video to NTSC video that can be easily captured using a capture device or VCR. An image of Mr. Video is shown below in Figure 31.

In Figure 32, to prove similar functionality between these two ICs, block diagrams for the AD725 and BH7236 are shown side-by-side from their respective datasheets.

Both of these ICs do not utilize any memory, which is needed for a framebuffer, to convert from RGB to NTSC video. At most, a framebuffer in the converter would cause vsync tearing similar to what was seen in section VIIe, and not make the transitions look like MAME. This is because by the time the converter is receiving the frames, they have already been drawn by the arcade video hardware. Therefore, the frame buffer would only combine and distort existing arcade frames. A framebuffer of the VRAM on the arcade hardware itself is necessary to show the transitions that are seen in Mitchell’s tapes. No amount of delay, latency, or loss will cause the transitions to change from those produced on an arcade machine to those produced on an emulator.

For greater verification that the two-bit converter does not change the transitions in any way, the transitions produced from an experiment using the converter were examined. This test was completed by Chris Gleed in 2018 after being sent a two-bit converter by Twin Galaxies. Just as was claimed in Billy Mitchell’s tapes, Gleed uses the two-bit converter to convert arcade RGB video to composite video, and then this composite video is captured on a VCR. Finally, the VCR output is digitized using a USB capture device so it can be uploaded to Youtube.

The walkthrough of this setup is seen in citation [36], the video recording is seen in citation [37], and the forum post where Gleed posted this experiment is seen in citation [38]. The two-bit converter that Mitchell claimed to use in his setup is seen in Gleed’s walkthrough. In Figure 33, the barrel transitions from Gleed’s recording are shown.

As expected, the transitions from the Two-bit converter VCR output look exactly like the arcade transitions that have been demonstrated and analyzed throughout this entire paper. This is because the converter cannot replace the VRAM scanning method with the framebuffer “snapshot” behavior that is seen in MAME. This analysis further proves that no element in Billy Mitchell’s claimed setup could have produced MAME transitions.

VIII. References

[1] Trachtman, Paul (September 1981). “A generation meets computers on the playing fields of Atari”. Smithsonian. pp. 50–53 [52]. Archived from the original on March 19, 2006.

[2] “Players Guide To Electronic Science Fiction Games”. Electronic Games. 1 (2): 35–45 [36]. March 1982.

[3] https://web.archive.org/web/20080723195740/http://gamers.guinnessworldrecords.com/aboutus/twin_galaxies.aspx

[4] https://www.insiderintelligence.com/insights/esports-ecosystem-market-report/

[5] https://donkeykongforum.net/index.php?topic=366.0

[6] https://web.archive.org/web/19991006214540/http://twingalaxies.com/Rules1.html

[7] https://www.mamedev.org/history.html

[8] https://www.twingalaxies.com/game/donkey-kong-us-set-1/mame

[9] https://github.com/mahlemiut/wolfmame

[10] https://www.twingalaxies.com/showthread.php/149814-Please-help-me-MARP-it-is-lying-about-me/page28

[11] https://web.archive.org/web/20171116213101/https://www.twingalaxies.com/showthread.php/168098-Twin-Galaxies-Donkey-Kong-(Arcade)-Recording-Rules

[12] https://web.archive.org/web/20080222153901/http://www.twingalaxies.com:80/index.aspx?c=22&pi=2&gi=3852&vi=22

[13] T. Iki, “CRT Display,” [1989] Proceedings. The First International Conference on Image Management and Communication in Patient Care: Implementation and Impact, 1989, pp. 232-236, doi: 10.1109/IMAC.1989.693757.

[14] https://junkerhq.net/xrgb/index.php/Optimal_timings

[15] https://donkeykongforum.net/index.php?topic=2761.msg42026

[16] https://youtu.be/3BJU2drrtCM?t=191

[17] https://www.mamedev.org/releases/whatsnew_0196.txt

[18] http://www.arcaderestoration.com/printgamedips/2477/Donkey+Kong+US+set+2/Donkey+Kong.aspx

[19] https://www.arcade-museum.com/manuals-videogames/D/dkong1.pdf

[20] https://github.com/furrykef/dkdasm/blob/master/dkong.asm

[21] https://www.arcade-museum.com/manuals-monitors/sanyo-ezv19raster.pdf

[22] https://undumped.miraheze.org/wiki/List_of_Undocumented_Discrete_Logic_Arcade_Games

[23] https://github.com/mamedev/historic-mame/releases/tag/mame0115

[24] https://www.mameworld.info/mameinfo/download/NEWS.txt

[25] https://web.archive.org/web/20071004091553/https://www.emulator-zone.com/doc.php/arcade/

[26] https://mollylab-1.mit.edu/sites/default/files/documents/FastDetect2014withFigures.pdf

[27] https://www.youtube.com/watch?v=KYtJzRcvOzk

[28] https://www.history.com/this-day-in-history/ben-johnson-wins-gold-temporarily

[29] https://www.youtube.com/watch?v=atY1HCmSucU

[30] https://web.archive.org/web/20061122232925/http://www.twingalaxies.com/index.aspx?c=22&pi=2&gi=3852&vi=22

[31] https://www.kodak.com/ek/US/en/ShutterOperations.htm

[32] https://www.displayninja.com/what-is-screen-tearing/

[33] https://docs.mamedev.org/commandline/commandline-all.html

[34] https://pdf.dzsc.com/BH7/BH7236.pdf

[35] https://www.analog.com/media/en/technical-documentation/data-sheets/AD725.pdf

[36] https://www.youtube.com/watch?v=VfnHXjrm2g8

[37] https://www.youtube.com/watch?v=rCtPb2-iVVs

[38] https://www.twingalaxies.com/showthread.php/176004-Dispute-Jeremy-Young-Arcade-Donkey-Kong-Points-Hammer-Allowed-Player-Billy-L-Mitchell-Score-1-062-800?p=958889&viewfull=1#post958889

IX. About the author

Email: tfokkens@protonmail.com

I am a hardware engineer working out of San Jose, California. I received my bachelor’s degree in electrical engineering from Missouri University of Science and Technology (MST) in May 2021, and I will receive my master’s degree in December 2022. My background and research are in electromagnetic compatibility (EMC), intentional electromagnetic interference (I-EMI), power and signal integrity (SI/PI), and high speed digital systems.

My experience with the competitive Donkey Kong scene began when I joined the Donkey Kong Forum in 2014. From there, I improved my skills through the help of the community and became the youngest person to “kill screen” arcade Donkey Kong at the age of 16, in January 2015. In October 2015, I achieved the world record on the “hard ROMs” version of Donkey Kong (as seen in Guinness Book of World Record Gamer’s Edition, 2017). In November 2015, I achieved 1 million points in the standard version of Donkey Kong. In early 2019, I founded Snektronix Incorporated with the help of two other community members, where we designed the Donkey Kong direct capture device called Mr. Video. These devices are available at Facebook.com/snektronix. In July 2019, I achieved 1,116,400 points on Donkey Kong, which put me at #10 on the arcade leaderboard on Donkey Kong Forum at the time.

My involvement in the Billy Mitchell dispute began in January 2016, when I uploaded the tape recordings that were later used for the initial analysis of the transitions. Since then, I have collaborated with individuals to compile technical evidence regarding Donkey Kong transitions to understand the differences between Arcade and MAME video.

Given my own personal love for this community and how many opportunities it has afforded me, I wrote this document independently in hopes that the drama and vitriol associated with the Billy Mitchell dispute can be put to rest in the court of public opinion. Additionally, the cross section of arcade gaming and electrical engineering was seminal to my early foundations as an electrical engineer.

X. Expert Verification and Peer Review

Various experts in classic arcade gaming, video game development, emulation, and hardware engineering were contacted to verify that the contents of this paper are credible and accurate. This is an informal version of peer review that would occur when a scientific paper is submitted to a journal for publication. All the expert verification statements that were obtained at the time of publication for this version of the paper are shown on the subsequent pages. These statements are also available at this document’s origin in PDF form. All formatting and font sizes that were chosen by each expert was left the same to avoid editing any part of their statement.

Any person who has appropriate credentials who would like to provide their own verification of the contents of this paper can contact the author at tfokkens@protonmail.com. Additionally, any errors or suggested changes are welcomed to further improve this document.

---

Fokkens’ analysis concludes with six expert verification statements. Those can be downloaded in pdf form here:

John Kowalski – https://perfectpacman.com/wp-content/uploads/2022/09/Fokkens-Kowalski.pdf

Barry Rodewald – https://perfectpacman.com/wp-content/uploads/2022/09/Fokkens-Rodewald.pdf

Jeremy Young – https://perfectpacman.com/wp-content/uploads/2022/09/Fokkens-Young.pdf

David Race – https://perfectpacman.com/wp-content/uploads/2022/09/Fokkens-Race.pdf

Wes Copeland – https://perfectpacman.com/wp-content/uploads/2022/09/Fokkens-Copeland.pdf

Carlos Pineiro – https://perfectpacman.com/wp-content/uploads/2022/09/Fokkens-Pineiro.pdf