Help 4-Board Donkey Kong Video/Sound Problem (PICS/VIDEO)

[DonkeyKong]

Ok, I finally got my 4-Board Donkey Kong set and plugged everything in and powered it up.

I was so looking forward to playing some Donkey Kong tonight to brighten up my really crappy last couple of days.  Unfortunately it's broked, borked, and snafu'd.  I'm keeping it together, at least for a few more minutes... and then I might just curl up in a ball and cry... oh just kidding.

The following are all upright pics in succession as the game boots up.  The last item is a video of this action and the looping nature of the sound and video on the last screen.

I've checked this against the Donkey Kong Technical Info site and it doesn't match any of the pictures there.  Something is seriously borked.

Anyone have any good advice??







This video will show the screen 90 degrees rotated to the left from an upright position.  I just wanted to get more resolution on the screen.  The first jump sound is the first sound the machine makes immediately after the power switch is turned on.
http://www.everybodytothelimit.com/donkeykong/dk4brd_bad4_rotated_left90deg.mpg (3.24MB)

EDIT: The machine is an original DK jr. with a Donkey Kong 3 kit installed.  It was working perfectly as a DK3 just before I swapped the PCBs and wiring harness.  The monitor is a Sanyo 20EZ with a new cap kit installed.

Here are some documents that I'm using to help me debug this project:

Donkey Kong TKG3-UP Manual (4-board)

Donkey Kong TKG4-UP Schematics (2-board)
(I wish I could find the 4-board schematics)

Sharp LH0080A Z80A CPU

Intel M8257 DMA

AMD M8257 DMA

Brasington DK Tech Info Site

A Guy With The Exact Same Problem As Me
(I contacted him and he had ended up giving the board away before it was fixed)

Thanks!
-Brett

[WunderCade]

I have a 4-board set and let me tell ya, I'd swap it for a 2 board version any day...they are proned to these problems. What you have here reminds me of what my board set did while I had the 5G rom removed for repair...the same sort of garbage and sound on the screen.

You may have a bad rom that needs replacing...you should start by removing cleaning and then reseating all the removable eproms, especially the ones listed on the brasington site. If that doesn't work....

You can test via a multimeter...that gets very involved and technical. More than likely if reseating don't work, you'll have to order a new set of eproms from mikesarcade.com OR arcadeshop.com or some members on the boards. You can also send it in to mikesarcade to be fixed or swapped. But that's a whopping $90.00. For that amount, you can prolly get a WORKING 2board set off feeBay.

The video issue you are having with the screen falling off on the left side is a horizontal hold issue that can be adjusted out. Check out the threads here  AND  here for that exact issue.
 

[DonkeyKong]

Thanks for the reply WunderCade.  Yeah I definitely realized that the 2-board set was the way to go early on, but I just HAD to play it ASAP.  I saw another 2-board set sell on ePay the other day for $98, before I even received mine that I won about 2.5 weeks ago.

The other reason the 4 boards stink is that the Z80 processor is sometimes soldered down, making a high score save kit a pain to install.  And last but not least, there is no edge connector for easy board swapping (my cabinet is actually wired with the edge connector).

I will try the removing and cleaning and reseating of the eproms.  I have the equipment to burn new ones, but if I had to hunt down the files and new eproms it might not be worth it to do it myself.  For the price I've paid it's really not worth it to spend any more money on this boardset.

Your answer to the video problem surprised me because it was working perfectly with my DK3 boardset, but I guess if the timing is a little different between boards just a bit this could still happen?

The other thing to note is that just about all of the eproms on the board don't have any sticker over the window... and who knows where this board was sitting and what light was shinning on it.  I know of at least one flash image that was taken of it though (for evilBay).

I'll do some work on it tonight and report back what changes if any there are.  Thanks!

[DonkeyKong]

Ok, so far I've inspected the board over and found a logic chip with pins 1-10 up out of the socket and pins 11-20 in the socket.  The pins were very nasty and corroded on both sides actually.  The logic chip is 2P on the TKG3-06-CLK board, a SN74LS299N.  I really didn't feel good about putting it back in the socket... it still seemed dirty a little and one of the pins was very loose.  Powering up the board had the exact same faulty screens and sound as first posted.

I think I'll order 4 new 74LS299N's for 2N, 2P, 2R, and 2S, and try to clean those sockets the best I can; insert the new ones and check the continuity of the pin to pcb and then see if it's still broken.

All of the EPROMS look well socketed and the pins are much cleaner looking than these logic chips.

Assuming I go after the EPROMS next, I have the Donkey Kong roms for MAME... haha, and I can use them legally!  Looking inside the ZIP I can see the bin files are labeled to match the EPROMS on the board.  I should be able to use those bin files and reprogram and new set of EPROMS, but what about just verifying the code in the EPROMs on the board first, and how about reprogramming the ones I have? (assuming they are not damaged, just got erased by sunlight or something)

I'm also trying to work out a trade with MikesArcade where I send them my poopoo 4-board and some cash, and they send me a working 2-board.  If it is as simple as fixing some logic and reprogramming the EPROMS though I can do that for not much cost, just time.  It might be worth it, but I still would prefer the 2-board stack - so in the end it really might not be worth the trouble.

edit: clarification

[D_Zoot]

Looking inside the ZIP I can see the bin files are labeled to match the EPROMS on the board.  I should be able to use those bin files and reprogram and new set of EPROMS, but what about just verifying the code in the EPROMs on the board first, and how about reprogramming the ones I have? (assuming they are not damaged, just got erased by sunlight or something)

Yes, you can  load a bin file into your programmer interface and use the "verify" option to see if the contents of any eprom matches the image in the corresponding bin file.   

BTW, erasing eproms with sunlight,  or corrupting the contents of an eprom just from the window sticker being missing is harder to do that you would suspect.  The wavelength of light needed to erase the eprom is pretty specific and it's a narrow band.     I sure would "verify" those eproms before assuming they were bad and dropping a whole new set into the board.


D

[DonkeyKong]

Yes, you can  load a bin file into your programmer interface and use the "verify" option to see if the contents of any eprom matches the image in the corresponding bin file.   

BTW, erasing eproms with sunlight,  or corrupting the contents of an eprom just from the window sticker being missing is harder to do that you would suspect.  The wavelength of light needed to erase the eprom is pretty specific and it's a narrow band.     I sure would "verify" those eproms before assuming they were bad and dropping a whole new set into the board.

Thanks D.  Yeah I've always heard that rumor about EPROMs being corrupted with sun or a flash, but I know it takes several minutes of intense UV baking to get them good and erased.  I will verify for sure first.

[DonkeyKong]

A little update.  I took the CLK board off of the 4-board stack and ohm'd out the 4 logic chips that are socketed.  They were all fine, and their diode junction signatures seemed to all match each other (except for when two had certain pins grounded vs. not on the other two, etc..).  There is also a PROM at 5F on the CPU board (if I remember correctly) that was pretty corroded on the pins.  I just cleaned it up and resocketed it.  Trying the board again tonight yielded no new changes unfortunately.

One more thing I tried was flipping the dip switches on and off a bunch to see it they were open, and maybe fixing them.  I still want to ohm them out and see if they are good, but that didn't help or change anything.

I decided to try to make a small step forward and fix the vertical tearing as shown in the first pics of this thread.  I didn't want to mess with the pots on the monitor since they worked for the Donkey Kong 3 board set just fine, so I started playing with VR1 and VR2 on the Donkey Kong 4-board set.  It turns out that VR2 (left/right adj.) fixed the tearing problem.  I think the pot was just dirty so I tweaked it back and forth a bunch and now it adjusts the picture left and right and only does the tearing in a few spots.

So searching through posts on rec.games.video.arcade.collecting yielded something REALLY interesting.  Someone with the exact same problem as me! 

CHECK OUT THE THREAD HERE

He tried a bunch of different stuff, and even replaced the ROMs, and still no change.  I've posted/emailed him to find out if he ever fixed it, but it's not hopeful.  Still though, this is at least encouraging that some -one- thing is failing and causing this to happen.

It's interesting to note that I've found many people reporting that the JUMP sound is the first sound they hear when powering up the machine (even though MAME makes a DK growl sound upon startup See below for the correction on this).  As if the machine is starting to execute the right code, and then starts to screw up big time and goes into a loop of garbage characters and the death sound.  Actually it's interesting to note also that the characters on the looping screen are the mario 1-up sprites over and over again, in slightly different shades.  It seems like the addressing is seriously messed up, to the point where the same section of RAM or ROM is being accessed over and over again. 

Does anybody have any expert advice on how to debug this with MAME in debugging mode?  Can I simulate RAM failures and addressing failures easily?  I think I might need to replace the RAM and/or check all traces that address and select the RAM.

-Brett

edit: corrected myself

[DonkeyKong]

A little more work done and no change in the condition of the patient.

I removed, cleaned and re-socketed everything that was in a socket or had a connector.  I inspected the traces on the sound board and the clock board in detail and did not find anything worth resoldering.  I inspected the Z80 processor and touched up a few points on it that looked potentially cracked or just didn't have much solder on them.  I cleaned up a couple dirty areas of the cpu board with rubbing alcohol (but there are many more dirty areas mind you).

So no change in doing all that.  Some part or prone trace must be bad... hmm, how to determine that without replacing everything one at a time... that's the question.

What could I use to wash the boards down and get the 26 years of dust and grime off of them without being too forceful?  Water and a toothbrush or would rubbing alcohol be better?

[DonkeyKong]

It's interesting to note that I've found many people reporting that the JUMP sound is the first sound they hear when powering up the machine (even though MAME makes a DK growl sound upon startup).  As if the machine is starting to execute the right code, and then starts to screw up big time and goes into a loop of garbage characters and the death sound.  Actually it's interesting to note also that the characters on the looping screen are the mario 1-up sprites over and over again, in slightly different shades.  It seems like the addressing is seriously messed up, to the point where the same section of RAM or ROM is being accessed over and over again.

I wanted to correct my statement here.  After checking out Donkey Kong (US set 1) in MAME, I can say that the jump sound is definitely first, but before it ends the growl sound starts and runs for a longer time than the jump.  This is probably why people say that the growl is first in MAME, it's just the most obvious sound.  I'm not sure if this is the same case in the hardware version (2-board or 4-board).

I'll be working on doing some things with the debug version of mame to see if I can figure out what's really going on with my board.  As I understand it, the in-game sound effects are "triggered" by the main processor by pulsing or setting a particular pin on some latches that interface with the sound processor.  Then the sound processor just plays the sound.  Obviously my board is looping the same video and sound sequence over and over.  I'll report back later after I've had a go at debug mode in MAME.

[DonkeyKong]

Debugging in MAME is a lot harder than I thought it might be.  Even though you can single step through the code, it's very difficult to know what's going on.  I did find a memory map of the Donkey Kong PCB, which is helpful, but trying to find where those addresses are accessed is harder because you cannot search through the disassembly to set breakpoints.  Bah.

Anyhoo, this is more interesting... I hooked up my EPROM programming gear and I was shocked that it all still works.  I was able to go through all of my EPROMs and compare them against the bin files in the dkong.zip rom file.  There were 4 of the 12 EPROMs that did not verify properly, so I read the data out so that I could compare to the data from the dkong.zip ROM images.  Only 1 of my 3 differing 4k*8 CPU rom images looks like it's suffering from bit fade.  The other 2 look like the code is just different.  For example, remember the old easter egg in the donkey kong rom image that says if you find this to call us because you must be hot sh*t?  Well my EPROM has the whole block of text, whereas the one in the dkong.zip file only has the second part of the message.  This leads me to believe mine is right.  The other differing EPROM is one of the video 2k x 8 chips.  I think mine is fine because it's a solid block (16 bytes) that is in the midst of a bunch of other blocks of all zeros.  My block has all zeros, and the supposedly good dkong.zip rom image has a bunch of different non-zero bytes for the entire block.  If you looked at this in a hex editor it just looks out of place.

Obviously my board isn't working, but it might be just because of the one bit faded EPROM.

I will provide detailed images of the differences in a hex editor if anyone cares (requests it).

What I would like to know though, is how can I get the data that I read out of my EPROMs into a working dkong.zip file?  I've renamed my bin images as they are in the dkong.zip file and replaced the ones in that file with mine, but mame complains that I'm missing one or more ROM or CHD images.  It's obviously looking for a proper checksum, so how can I make it match?  Anyone savvy on this?  Thanks!

Aside from trying to make MAME run like my board does, I will then attempt to erase and reprogram the one suspected CPU board EPROM.

[DonkeyKong]

So the thing with the one particular CPU EPROM was that is seemed to be exhibiting bit fade, but really when I compared the bits that were not matching they were always LOW.  Never was there a high bit when it should have be low.  And to compound matters every time I would read the data from that particular EPROM it would give me slightly different bits in error.  I decided just to try and erase it and reprogram it, but after 30 minutes under the UV it was reading mostly 00's and some bits were stuck high.  This is exactly the opposite of what it's supposed to do (return high when erased).  So it must have a flaky enable pin or something, I don't know but you are going to love the next sentence...

I figured I could pull all 4 of the CPU program EPROMs out and power up the board to see what if any difference there would be, and to my surprise IT WAS DOING THE EXACT SAME THING!

Now I know that at least 3 of the 4 CPU program EPROMS were fine, and the last one was intermittent - bad, but definitely not completely dead or anything.  The rest of the EPROMs are fine as well.

So I'm really leaning towards the Z80A being toast, or it's not getting a clock (XTAL) or something.  I won't know what's up with it until I bring home an oscilloscope from work tomorrow.  Apparently I need a new TMS2532 EPROM now as well, if anyone has one they can send me I can paypal you some funds.  Or we could work out a trade, I have a buttload of 27C256 EPROMs.

edit: trade info

[WunderCade]

PM'ed

[DonkeyKong]

I brought home a scope tonight and have been probing for about 4 hours now.  The Z80A is getting a proper 3.072MHz clock.  The Z80A also appears to be working, but I'm not super sure what exactly it is doing.

If you reference the video in the first post, the Z80A stays in reset for about 1 second while the sound processor powers up instantly and starts playing the jump sound.  The screen changes to the second image as soon as the Z80A comes out of reset, as well as the death sound is triggered.  When the death sound triggers once more the screen changes to it's final appearance of uniform jumpman 1-UP characters.  If I watch the upper address lines of the program EPROMS, they are toggling for about 60ms every 2.8 seconds after the Z80A comes out of reset, and for a 25us every 42ms in between the 60ms bursts.  The lower 8 bits of the address are toggling uniformly and continuously (I think due to the DMA, read more below).  This whole action will continue on with or without the program EPROMs in their sockets (and I know that only the EPROM in the middle of the program range has issues, so if code was executing there would be some difference between EPROMs in and EPROMs out).

Noted after a while was the Z80A, the D8257C (DMA) and the six 2114 RAM ICs were all fairly warm.  I didn't think they would be this warm but then again this is my first arcade PCB.  I suppose they would be warm if continuously running through a ton of addresses.

So the question now is, WTF?

Just kidding... seriously though, the question I have is what is the Z80A suppose to do, and how could it not do that assuming everything I've mentioned thus far?  Reading the datasheet for the SHARP LH0080A Z80A processor, it seems like with a valid clock it should start to access the lowest address, PC=0000 and start executing code.  If it does not see the code for some reason it would execute NOP's (assuming it reads 0x00 for the data).  The D8257C (DMA) is toggling the /BUSRQ at the same rate that the upper address bus range seems to be toggling.  When the DMA requests the address and data bus, it just has to toggle that line and the Z80A goes high impedance.  I don't fully understand all of the memory and ram access yet, but I'm sure the video and maybe the sound blocks need to access to the bus as well.

If there is anyone out there that has some expert advice for me, my ears are open   If I had a logic analyzer I'd be hooking that up as well, but I do not.

Here is the SHARP LH0080A Z80A DATASHEET if you want to scope it out.

Help?

[D_Zoot]

I'm not really at all familiar with DK boards, so it's entirely possible I don't know what I'm talking about,  but have you probed around the chip select circuits and supporting logic?   If the /CS logic is goofed the cpu might be trying to load incorrect blocks of code.

Once it comes out of reset, does it ever cycle reset again?  Is the watchdog getting refreshed?

D

[DonkeyKong]

The intial reset circuit is just a 10k resistor charging a 100uF capacitor that drives one leg of an inverted input OR gate.  The output of that drives the reset for the DMA and the some D LATCHES that drive triggers for in game sound effects.  The reset line is inverted and brought to the Z80A.  This circuit stays at the active reset state for one second initially and then never resets again.

The chip selects for the program memory and RAM seem to be toggling.  If there were code coming out of them I would think the Z80A would be running that code.  Unfortunately I don't know the duration of what devices need access to the bus, but I would assume the video needs the most.  I thought the video had it's own 2k of RAM.  Looking at the program code, the Z80A enables it's interrupt and then starts clearing RAM from $6000 to $6FFF.  I don't think that's happening on my board though, and even if the RAM was bad the Z80A doesn't run any tests to verify that it's actually clearing RAM.

I don't believe there is a watchdog circuit.

I think I'm going to wash the boards down real good and see what if anything happens after.  I need to take a step back. 

Maybe someone can tell me how to run my own code in MAME, in place of the dkong.zip.  I'd like to just make it loop a NOP at $0000 and see what the rest of the hardware does based on that.

EDIT: I found a version of MAME called TinyMAME.  It was built just to run donkey kong apparently.  In this version I was able to run my dkong.zip file filled with MY data from my donkey kong EPROMs.  It worked just like normal, except when you got to the first level the screen would freeze.  No doubt because the code in the second bank of EPROMs is flakey.  So that solves it!  heh... um, not.  But at least I know my code works.  Now to find out what happens if the code is looping NOPs, well later tonight maybe.

-Brett

[DonkeyKong]

Maybe someone can tell me how to run my own code in MAME, in place of the dkong.zip.  I'd like to just make it loop a NOP at $0000 and see what the rest of the hardware does based on that.

EDIT: I found a version of MAME called TinyMAME.  It was built just to run donkey kong apparently.  In this version I was able to run my dkong.zip file filled with MY data from my donkey kong EPROMs.  It worked just like normal, except when you got to the first level the screen would freeze.  No doubt because the code in the second bank of EPROMs is flakey.  So that solves it!  heh... um, not.  But at least I know my code works.  Now to find out what happens if the code is looping NOPs, well later tonight maybe.

-Brett

Ok, so I did end up figuring out what happens if there is NO program memory code running in MAME.  I couldn't figure out quickly how to just insert a NOP at location 0000 and then a JMP to 0000 at the next program memory location... I had the bin2hex.exe, and was hoping to just switch around some OPCODES and convert it back to a bin file, but I couldn't make heads or tails of the HEX file in relation to the disassembly shown in the debug version of MAME.

What ended up doing is I just made ALL 16K of the program memory locations in the BIN files 0x00, and ran that in the TinyMAME I found because it complains about the bad checksum, but runs the code anyway.  When the game loads, you hear the Donkey Kong Growl play once, the screen fills with '0's and then the DK Growl just keeps looping!  This has a very close resemblance to my problem, but obviously a little off because I'm thinking the dkong.c driver that was used to build this version of tinymame is old.  I know when playing the game, certain sounds are not heard.   All emulated Donkey Kong's fill the screen with '0's instead of the proper garbage characters that you would see on your real donkey kong machine.  (take any working boardset and power it up and get the monitor warm... turn the power off and on again rapidly while watching the screen... you should see characters on it for a split second before it goes to the insert coins screen.  This garbage that is displayed is the same every time, and not random)

So to see if I could truly emulate my board problem, I got the newest version of the dkong.c driver, and set off to figure out how to compile a tinymame with it.  So far I've scoured the internet, and downloaded and installed the mame SDK... or the files that will allow you to build a version of mame for yourself.  I haven't tried compiling the newest mame yet, but I haven't seen anyone talking about how to build one of these tinymame's.  If anyone knows how to do this PLEASE chime in.

The next step for me on this board is to replace the Z80A with a socket and see what happens when it's not even in the board.  If it's the same thing, I'm going to try replacing the Z80A and pray that fixes it.  Does anyone have one of these Sharp LH0080A Z80A CPU's you would like to part with?

Oh, I also got myself a working 2-board set for $31 plus $18 shipping ;-)  I kind of got lucky on a board that was claimed to have a blue screen... I plugged it in and it just worked straight away.  So I have something to compare to... oh actually I have a Z80A on that board that obviously works and is socketed... hmm... ^_^  I'd hate to mess with it, but it's gotta come out of there when I get my highscore save kit anyway.

[pcb]

If you have a high score kit, it will replace the roms on the board, and do a memory test if it can run.  They are very helpful when troubleshooting.  I use one all the time on all DK and DKJr board sets.  That being said, most of the time, it's not a ram or rom that has gone bad.

On a 4 board set, remember there are 3 power connections and all need to be connected to get the board to run.  Also, they LOVE -5V, 0.4Amps is marginal 1.0Amp is preferred from the power supply.

Another thing to think about is the CPU board may be fine, it might be a different board in the set.
I just finished a marathon fixing these and they are not difficult, but you need to have a working set to make them easy.  I mix the bad set with the working set to see which board is actually the bad one, and go from there.

I do have schematics for the 4-board set scanned, but they are in little chunks at the moment.  Next week I play on pasting them back together and posting a PDF on my site.

Good luck, I know how frustrating it can be when you don't have a working set to compare against.

 - Mike -
FYI,  you probably have the dkongo set, not the dkong set.  The 4-board version came with the dkongo set originally, and many of them still have that set installed. 

[DonkeyKong]

If you have a high score kit, it will replace the roms on the board, and do a memory test if it can run.  They are very helpful when troubleshooting.  I use one all the time on all DK and DKJr board sets.  That being said, most of the time, it's not a ram or rom that has gone bad.

Cool, I didn't know that.  All the more reason to get my high score save kit on order.

In your experience, what are you finding bad on a board exhibiting problems like mine (if you've ever seen something like that)?

On a 4 board set, remember there are 3 power connections and all need to be connected to get the board to run.  Also, they LOVE -5V, 0.4Amps is marginal 1.0Amp is preferred from the power supply.

Yes I do have the 7 pin SOU cable plugged in, but isn't that just power for the sound board?  The sounds do seem to be working. 

It sounds like you have made adapters for your power cables to test the current flow in various power buses... that's very smart ;-)  Do you have a cheat sheet on those currents that you would be willing to share?  I actually didn't even do the basic voltage check on the different power buses.  I suppose that would be helpful!

Another thing to think about is the CPU board may be fine, it might be a different board in the set.
I just finished a marathon fixing these and they are not difficult, but you need to have a working set to make them easy.  I mix the bad set with the working set to see which board is actually the bad one, and go from there.

I do have schematics for the 4-board set scanned, but they are in little chunks at the moment.  Next week I play on pasting them back together and posting a PDF on my site.

Yeah, that would be great if I had the ability to swap boards.  I do have the working 2-board now, but without an schematic it will be a little bit hard to compare one chip's signals to another's.  I've been able to find various chips, but I have to analyze the traces and components connected to it.  The 4-board schematic you have would be much appreciated by everyone, I'm sure.

Good luck, I know how frustrating it can be when you don't have a working set to compare against.

 - Mike -
FYI,  you probably have the dkongo set, not the dkong set.  The 4-board version came with the dkongo set originally, and many of them still have that set installed. 

Thanks for stoping in at my thread and giving me some tips Mike!  I'll be sure to post back when I have some updates.

[pcb]

Start by doing a voltage test where the power comes into the CPU board.  That will tell you at least if you are getting close to what you need in the way of voltages.

You can use your DK 2-board set roms in the DK 4-board set also.  Here's Scott's page with the locations crossed between board sets:

http://www.brasington.org/arcade/tech/dk/

Best,

 - Mike -

[DonkeyKong]

So I replaced the Z80 processor in this board... and... it's still doing the same thing.  I've tried a known working processor as well.  This board has serious issues.

I know this is an old topic, but I thought I would try to post whatever I do to this board so that others may benefit.

I still want to put my Brasington HS Save kit in this board and see what the power up self test says... but the pin header on this Save Kit doesn't plug into a standard IC socket.  So I'll have to solder a standard IC socket to the bottom of the pins before it will plug into the socket I put on my 4-board set.  I suppose I could have put a different socket in there that accepts these huge square header pins, but we didn't have any for FREE at work

EDIT: I also have a new problem with my working 2-board set, if you wouldn't mind looking over here:
http://forum.arcadecontrols.com/index.php?topic=83374.0

I think I posted that in the wrong place though...