Billy Mitchell's Direct Feed Recordings are MAME Generated

[Sqrlmonger]

^Good info.

The crystal on the TBS encoder is 3.57mhz.  The instructions say to convert it to PAL, replace the crystal with one of frequency 4.48 mhz and move a jumper.  I tried moving the jumper alone, and got a black/white signal out of it that was black/white on all devices.

Hopefully it is of some use to you guys, I wasn't sure if I was sticking my nose into something you already knew way more about or not.

Regardless, I will say I was rounding the 3.58 Mhz number I listed, it's actually 3.579545 MHz for the NTSC color standard subcarrier frequency (had to look it up) and it is in fact 4.43361875 Mhz for the PAL.

However, when I was snooping about I came across something I didn't really remember at all which is this:

https://en.wikipedia.org/wiki/NTSC#NTSC_4.43

Essentially, there is another NTSC format called NTSC 4.43 which uses a 4.43 Mhz color subcarrier frequency. It is theoretically possible this is what you guys are dealing with. For those who knew about this feel free to laugh, my knowledge of these standards is not the greatest. So if there are those with better knowledge please step in and I will happily let you folks sort this out.

As such, again, please keep in mind I am just piecing this all back together myself, so take everything with a grain of salt, etc.. etc..

Cheers~

[Sock Master]

Jace recently posted a bunch of information regarding Mr Mitchell's recording methods and how they seem to be capturing a mono-chromatic recording.

The reason the Two-Bit and other similar RGB to NTSC devices will not generate a proper composite color output is because these devices use the H-Sync pulses that are output by DK hardware to figure out where the colorburst reference should be inserted into the composite video signal.
Both H and V syncs generated by DK hardware are not up to NTSC specification.   An RGB monitor wouldn't care if the H-Sync is the wrong width - it only cares that it's there at all, so it'll happily display video.   NTSC composite video on the other hand contains additional reference signals at specific points in time to tell the receiver the frequency and phase of the color carrier that's needed in order to decode colors.
The short explanation is if the H-Sync pulses are too wide or too narrow the RGB to NTSC converter will not insert the colorburst signal into the correct time window.   If the signal is not positioned correctly a VCR/TV/etc will have difficulty locking to the color carrier, hence have difficulty decoding the colors or even fall back to legacy B&W mode.

[smf]

Based on NTSC standards a normal domestic (US) VCR is probably expecting a ~3.58 Mhz chrominance subcarrier frequency but I have no idea what the setup is actually generating.  Taking a look at some of the PAL standards it's possible there are some VCRs out there that just might get some color out of the setup, but no telling if it would be accurate.

There is an added complication because VHS doesn't have enough bandwidth to store the NTSC signal.

https://electronics.stackexchange.com/questions/173626/video-home-system-vhs-bandwidth

The VHS recorder assumes a lot about the incoming signal and won't tolerate anything that doesn't closely match the NTSC specification. Home computers in the 1980's didn't output legal NTSC (or PAL) signals either, good enough for monitors but a lot of VHS decks had problems. Some VHS decks are more tollerant than others (both recording and playing back), some people could only get B&W recordings while others could get colour.

It's pretty difficult to create an interlaced output from a direct feed from an unmodified donkey kong board, yet on the TG thread they are talking about odd and even frames. It's possible that when the VHS was transcoded the software expected the source signal to be interlaced and that has introduced artifacts.

Or the donkey kong board may have been hacked to produce a more valid NTSC signal, which will change the cpu's timing relative to the video output. Every scan line in a progressive frame is the same length, while an interlaced frame has one line that is only half the length of all the others. This affects the frame rate, changing the frame rate in MAME is what caused the transitions to change. This might be enough to create the MAME transition from an arcade board and will likely change the random number generation as well. Billy might be correct in saying it's not MAME and he may not have intentionally cheated, but it doesn't mean the score is valid.

[Sqrlmonger]

The reason the Two-Bit and other similar RGB to NTSC devices will not generate a proper composite color output is because these devices use the H-Sync pulses that are output by DK hardware to figure out where the colorburst reference should be inserted into the composite video signal.
Both H and V syncs generated by DK hardware are not up to NTSC specification.   An RGB monitor wouldn't care if the H-Sync is the wrong width - it only cares that it's there at all, so it'll happily display video.   NTSC composite video on the other hand contains additional reference signals at specific points in time to tell the receiver the frequency and phase of the color carrier that's needed in order to decode colors.
The short explanation is if the H-Sync pulses are too wide or too narrow the RGB to NTSC converter will not insert the colorburst signal into the correct time window.   If the signal is not positioned correctly a VCR/TV/etc will have difficulty locking to the color carrier, hence have difficulty decoding the colors or even fall back to legacy B&W mode.

A lot of this is good added info, thanks.  But to clarify when you're talking about the "correct time window" we are just talking about lining up with the zero phase of the sub-carrier frequency, no? If not, I would be grateful if you could explain my misunderstanding. Thanks!~

There is an added complication because VHS doesn't have enough bandwidth to store the NTSC signal.

https://electronics.stackexchange.com/questions/173626/video-home-system-vhs-bandwidth

The VHS recorder assumes a lot about the incoming signal and won't tolerate anything that doesn't closely match the NTSC specification. Home computers in the 1980's didn't output legal NTSC (or PAL) signals either, good enough for monitors but a lot of VHS decks had problems. Some VHS decks are more tollerant than others (both recording and playing back), some people could only get B&W recordings while others could get colour.

It's pretty difficult to create an interlaced output from a direct feed from an unmodified donkey kong board, yet on the TG thread they are talking about odd and even frames. It's possible that when the VHS was transcoded the software expected the source signal to be interlaced and that has introduced artifacts.

Or the donkey kong board may have been hacked to produce a more valid NTSC signal, which will change the cpu's timing relative to the video output. Every scan line in a progressive frame is the same length, while an interlaced frame has one line that is only half the length of all the others. This affects the frame rate, changing the frame rate in MAME is what caused the transitions to change. This might be enough to create the MAME transition from an arcade board and will likely change the random number generation as well. Billy might be correct in saying it's not MAME and he may not have intentionally cheated, but it doesn't mean the score is valid.

That all makes sense...except I think where the TG thread is discussing the odd/even frames they are not referring to the interlaced frames generated from the source as even/odd so much as they are talking about the issue resulting from a 60.6 Hz source captured by a 30 Hz medium. Which of course results in only half of the interlaced source frames being captured.  So where you are referring to source frames as interlaced odd/even frames (accurately so) they are referring to the frames recorded as odd or even in terms of which of the interlaced source frame is actually captured and which is lost to 2:1 source:medium refresh rate discrepancy.

Hopefully, that made sense and I actually understood you anyways.

Cheers~

[Sock Master]

A lot of this is good added info, thanks.  But to clarify when you're talking about the "correct time window" we are just talking about lining up with the zero phase of the sub-carrier frequency, no? If not, I would be grateful if you could explain my misunderstanding. Thanks!~

I don't actually have a Two-Bit RGB to NTSC converter to check what its output looks like, but I do have a different RGB to NTSC converter that works fine when connected to other devices.  When connected to a DK PCB, it also exhibits black and white output.

Here's a photo of what the composite hsync / colorburst looks like on a scope.   Sorry for the terrible picture quality, it was difficult to take a photo of the oscilloscope.

It seems the syncs coming from the DK PCB confuse the RGB-to-NTSC chip and the composite sync and colorburst is pretty messed up looking - The signal levels are wrong. The timing is messed up. The colorburst seems to be too short.  I haven't made full sense of the why yet, but it's safe to say most NTSC devices are going to have trouble decoding colors from this video signal.

[colecomeister]

Based on NTSC standards a normal domestic (US) VCR is probably expecting a ~3.58 Mhz chrominance subcarrier frequency but I have no idea what the setup is actually generating.  Taking a look at some of the PAL standards it's possible there are some VCRs out there that just might get some color out of the setup, but no telling if it would be accurate.

There is an added complication because VHS doesn't have enough bandwidth to store the NTSC signal.

https://electronics.stackexchange.com/questions/173626/video-home-system-vhs-bandwidth

The VHS recorder assumes a lot about the incoming signal and won't tolerate anything that doesn't closely match the NTSC specification. Home computers in the 1980's didn't output legal NTSC (or PAL) signals either, good enough for monitors but a lot of VHS decks had problems. Some VHS decks are more tollerant than others (both recording and playing back), some people could only get B&W recordings while others could get colour.

It's pretty difficult to create an interlaced output from a direct feed from an unmodified donkey kong board, yet on the TG thread they are talking about odd and even frames. It's possible that when the VHS was transcoded the software expected the source signal to be interlaced and that has introduced artifacts.

Or the donkey kong board may have been hacked to produce a more valid NTSC signal, which will change the cpu's timing relative to the video output. Every scan line in a progressive frame is the same length, while an interlaced frame has one line that is only half the length of all the others. This affects the frame rate, changing the frame rate in MAME is what caused the transitions to change. This might be enough to create the MAME transition from an arcade board and will likely change the random number generation as well. Billy might be correct in saying it's not MAME and he may not have intentionally cheated, but it doesn't mean the score is valid.

The DK hack sounds like it might be an interesting project if someone was curious enough. In the case of Billy, though, he's gone to great lengths to testify that, in order to avoid further King of Kong "shenanigans" about PCB tampering, he had the DK PCB independently verified as original/unmodified before and after he put up his 1.05 and 1.06 million scores.

http://www.mtv.com/news/1565744/donk...s-to-prove-it/

[smf]

That all makes sense...except I think where the TG thread is discussing the odd/even frames they are not referring to the interlaced frames generated from the source as even/odd so much as they are talking about the issue resulting from a 60.6 Hz source captured by a 30 Hz medium.

Broadcast quality NTSC is interlaced, but lots of systems output non standard NTSC and some VHS decks are tollerant enough to record them in color. This was posted a while back, it's full of wrong.
 
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=952279&viewfull=1#post952279

"Regarding VHS tape. It is not designed to record and play back progressive signals. It stores NTSC/PAL/SECAM/etc. which are interlaced formats. This is one of the reasons why the inverter board is used to record a direct feed to a VHS tape recorder and the RGB signal is no directly sent."

"Standard Composite and S-Video connections do not transfer progressive scan video images, so any RGB-to-Composite converter must output an interlaced signal."

Commodore 64 outputs a progressive composite video, it was certainly possible to directly hook that up to a VHS and record it in the 1980's.

Some modern TVs have real problems with progressive analogue video though. The manufacturers didn't bother to plug in an old games console. It affects some modern games consoles too though, some modern consoles with emulators have had to put the games out in interlaced (which changes the timing as the frame rate is slightly different 59.94hz vs 60hz).

The DK hack sounds like it might be an interesting project if someone was curious enough. In the case of Billy, though, he's gone to great lengths to testify that, in order to avoid further King of Kong "shenanigans" about PCB tampering, he had the DK PCB independently verified as original/unmodified before and after he put up his 1.05 and 1.06 million scores.

I'm not sure that Billy has the skils to modify a board, or tell if it's been modified. I get the impression he believes every thing his friends say and disbelieves everything his perceived enemies say.

I'd love to know who verified it wasn't modified & how they could tell. If there was money in it then I'd put an ARM cpu inside a z80 packaging and have it execute the roms on the motherboard in an emulator, but allow you to trigger tool automated speed runs. You'd need to decap the Z80 to find that.

It seems the syncs coming from the DK PCB confuse the RGB-to-NTSC chip and the composite sync and colorburst is pretty messed up looking - The signal levels are wrong. The timing is messed up. The colorburst seems to be too short.  I haven't made full sense of the why yet, but it's safe to say most NTSC devices are going to have trouble decoding colors from this video signal.

If your RGB to NTSC is unhappy, then this might fix it.

https://martin-jones.com/2014/09/16/that-syncing-feeling-classic-arcade-games-that-wont-stay-still/

[Rev John]

Look what I just found and posted to the BM DK dispute thread

See https://www.youtube.com/watch?v=Iirf4_jiX0Y&t=3h28m32s - Jace Hall is discussing one of Billy's MAME tapes

If you don't see the score bobble up then back down then back up within 2 seconds hit F5 and look again.  Or you can pause and hit comma and full-stop to scroll back and forth frame by frame.

EDIT: Jace Hall of TG has checked the original tape and the above score 'popping' does not appear on the original tape submitted by Billy Mitchell.  So what you can see in the link above must be some artefact of the FB stream / Youtube conersions.

[danman123456]

I thought that was brought up as a cut point on the DVD from Dwayne himself. That is why it overlaps a bit.

Look what I just found and posted to the BM DK dispute thread

See https://www.youtube.com/watch?v=Iirf4_jiX0Y&t=3h28m32s - Jace Hall is discussing one of Billy's MAME tapes

If you don't see the score bobble up then back down then back up within 2 seconds hit F5 and look again.  Or you can pause and hit comma and full-stop to scroll back and forth frame by frame.

[Rev John]

I thought that was brought up as a cut point on the DVD from Dwayne himself. That is why it overlaps a bit.

Look what I just found and posted to the BM DK dispute thread

See https://www.youtube.com/watch?v=Iirf4_jiX0Y&t=3h28m32s - Jace Hall is discussing one of Billy's MAME tapes

If you don't see the score bobble up then back down then back up within 2 seconds hit F5 and look again.  Or you can pause and hit comma and full-stop to scroll back and forth frame by frame.

We should get the "slow-mo guys" on youtube to analyze Billy's tape.

I've added an edit to my post above: "Jace Hall of TG has checked the original tape and the above score 'popping' does not appear on the original tape submitted by Billy Mitchell.  So what you can see in the link above must be some artefact of the FB stream / Youtube conversions."

There's still no explanation for the MAME frames, other than that Billy used MAME.

[Sqrlmonger]

Reference: TG Post #2661

I specifically asked Carlos how much more time he needs to get through his process, and I told him that we are waiting to include his findings and evaluate them before finalizing a decision. I also told him that we have limited time to wait for him. He understood and had no issue and indicated the desire to be done quickly as well.

He said he will provide TG with a time estimate shortly. I indicated that we have allowed for at least through the weekend for him to finish up his work, but a decision will need to be made very shortly after that no matter what.

There is a potential TG banning soon if anyone is interested.

[Weehawk]

He said he will provide TG with a time estimate shortly.

Or...you know...at least provide TG with an estimate of when they can provide an estimate of when they can provide the information...

[bh]

Crossposting from TG:

Attached is a visualization contrasting the rendering behavior of a genuine Donkey Kong cabinet and MAME. Original hardware performs a linear scan of video ram (upper left) writing the contents to screen (upper right). The Z80 CPU and video generation are on separate boards. Their behavior isn’t synchronized and the Z80 happily writes to video ram while the video board composes the screen. MAME took shortcuts and didn’t emulate this async interaction between the Z80 and the video generator. It reads the entire contents of video ram at once (lower left) and renders discrete frames (lower right).

This leads to pronounced differences in frame generation.

By image fourteen of the visualization MAME has completed it’s frame displaying three girders. The second girder is complete and reaches the left-hand side of the screen. Original hardware is only part-way through a frame and only showing three floating girders. By image thirty one, original hardware will have completed a frame showing five partial girders.

When MAME composes its next frame, ladders have already been written into video ram and appear in the output. These ladders won’t appear on real hardware until the linear scan completes it’s 3rd pass.

It’s also worth pointing out that girders are populated into vram from right to left while the arcade sweep line travels from left to right. The interaction between draw and scan crossing each other means that real hardware can show multiple partially drawn girders. Since MAME generates the entire framebuffer at once it does not display evidence of this interaction and only shows one partially drawn element at once - whatever the emulated Z80 happened to have drawn to at the time it was interrupted by the video emulator.

The take home message is that frame composition order differs between a Donkey Kong cabinet and MAME. These hallmarks are sufficient to conclusively identify whether a video shows MAME or arcade gameplay. Genuine hardware will always show five partial girders rather than the three girder pattern characteristic of MAME. Ladders won’t appear all at once on real hardware. No amount of analog signal processing will make a MAME frame look like an arcade frame and vice versa. Arguments that don’t address this are distractions at best.

The tapes released by Twin Galaxies look like MAME because they're MAME.

()

[johnbart]

This is an amazing visualization of the differences. The simulated scan line makes it so clear.

Thanks for putting this together.

[Sqrlmonger]

This is an amazing visualization of the differences. The simulated scan line makes it so clear.

Thanks for putting this together.

I'll let him post his final result set here, but there is more to come. I've seen he is working on the other boards on the TG forum. 

And I agree, it's very instructive (and cool) to be able to be able to visualize the difference.