Donkey Kong by Nintendo PCB #2
Here's the second Nintendo Donkey Kong PCB set on the bench for repair. This one is the later TKG4 type by Nintendo of America which belongs to a Donkey Kong upright arcade machine and comprises only 2, larger size PCBs compared to 4 slightly smaller boards for the earlier TKG3 set. It appears the Video and Clock PCBs of the previous version have been combined into a single new Video PCB. Likewise the previous CPU and Sound PCBs are now combined.
Although my previous test setup would still work with the later style PCBs, the TKG4 set has an additional 44 way edge connector to combine power, video, sound and controls into a single interface (with an additional 10 way 'rainbow cable' interconnection for power between the two PCBs). I've made up a new test cable to suit as this will simplify the connections and make it a little easier to turn the PCB set over to work on either the CPU or Video PCB.
The TKG4 board set also has provision for on board, inverting video output stages so the game could provide a more standard, positive video signal to work with other types of arcade monitor more common in the USA than the original Sanyo type. That section is unpopulated on this particular PCB so I'll still be using my external inverting amplifier to suit my test bench RGB TV monitor.
This one has an interesting fault involving the sprite of the 'damsel in distress' character Pauline. After the initial cut scene animation the figure stands at the top of the 'girder' level and comprises 2 sprites, one for the main body and one for the head. At the completion of the level the Kong character grabs Pauline and ascends further as a prelude to the next level.
At this point the head part of the figure appears just to the left of the original position while the body part is carried off giving the unfortunate appearance that the character has split in two - but the head part should not be visible at all as the Pauline body being carried by Kong is shown in a slumped position. So the appearance of the head sprite, off to the left of the original position is spurious.
Usually, if just an isolated game element seems incorrect rather than issues being more widespread I would suspect a program error as a result of a CPU ROM or related logic but in this case the fault has already been isolated to the Video PCB which exhibits the same issue when used with a different CPU PCB. The CPU board currently paired with the Video is working apart from a reported issue with missing sounds. At present those appear to be working perfectly so I'll come back to that later.
Here is the Donkey Kong Video PCB which exhibits an unusual graphics glitch with the position of the girl's head sprite. Tracing this type of fault where just one single artefact appears wrong while everything else seems to work correctly, is always a challenge. The solution will usually relate to a part of the circuit which is responsible for this particular detail without affecting the broader operation such as a bad memory location in the program or graphics ROM or a specific RAM area.
In this case many potential causes have already been eliminated as the problem has been narrowed to the Video PCB. The program ROM and main RAM are both contained within the CPU PCB so should be above suspicion. Nonetheless I'll begin by verifying all of the EPROMs and PROMs on both PCBs as well as running my RAM testing program which will check the main, video and sprite RAM for errors.
This should eliminate another potential problem, if the CPU and Video PCBs contain mismatched software versions that could cause unusual behaviour. So, checking all of the EPROMs and PROMs using my EPROM programmer with suitable adaptors, all of the files verify correctly against the Donkey Kong, US set 1 ROMset which is the correct version for this PCB set.
Moving on to the RAM testing, I'm placing the latest version of my Donkey Kong testROM into the boot ROM position on the CPU PCB. The previous version would complete a single pass of each RAM area then proceed to an endless 'reading every address' loop, intended to assist with signal tracing within the PCB.
The latest version aims to identify marginal or intermittent RAM errors by completing a single pass of each RAM area followed by one pass of reading every address before looping back to the very beginning. At any point if a RAM error is found the program will halt with a fail message for the relevant section otherwise the tests will repeat indefinitely. Powering on and allowing the test to complete several loops the results are as below.
After several passes of the test routines the main, video and sprite RAM were all found to be working. Although the test program ran correctly and results are readable there is an unexpected, random looking pattern of sprites visible on screen. This may not be a fault and appears to be due to the contents of RAM on startup which have not been cleared. When I ran the same test program on the earlier, TKG3 PCB set however the sprite layer was not visible upon startup.
It would seem the sprite 'garbage' must be originating from the ECL RAM in the clock section of the video PCB as it remained on screen while the other RAM areas were all completely overwritten during testing. At this stage I don't think the symptom relates to the sprite 'glitch' which I'm trying to locate and doesn't affect the game program which must clear or hide the sprite layer upon startup.
Getting back to the one sprite detail which appears incorrect during gameplay, the girl's head sprite seems to be shifted to the left at the moment where it should be removed from screen completely so the information which controls the position of that sprite may be corrupted. To get a better idea of the inner workings of the software I can refer to the MAME driver for Donkey Kong, I have also located a complete disassembly of the program with added comments, by furrykef on Github.
Reading the comments added to the disassembled program, a group of eight Bytes have been identified as containing the girl sprite attributes. These memory locations don't contain the pixel data but the X and Y position, character / pose selection and colour palette for each sprite with the very first Byte #6900 Hex being the girl's head X position. That's a good clue but the address #6900 Hex is within the main RAM on the CPU PCB rather than the sprite RAM bank on the video PCB.
Looking into the actual program space now and searching for comments relating to the girl sprite I've found the point where the girl's head sprite should be cleared. It seems the program achieves this by storing a zero in the sprite X position attributes. If this value is corrupted and a non zero quantity read instead the sprite would reappear shifted horizontally from its previous position.
Just to confirm if placing a non zero value in this location, at this point within the program could cause the exact fault symptom I'll try it - in MAME once again. To achieve that will take a few extra bytes of code so I've located some unused space within the ROM address range and will add a jump instruction to the additional steps followed by another jump to resume the original program.
Using a Hex editor to amend the ROM files as above, running the modified set in MAME the fault symptom is recreated exactly, as shown in the screenshot below. Finding the correct shift position did take some trial and error, starting with an estimated value of 50 Hex before arriving at the final position with a value of 40 Hex. This also makes sense as the correct value should be 00, to read 40 would only require a single bit to be incorrect (bit 6).
But this can't be the problem - as the address in question 6900 Hex is within main RAM on the CPU PCB and not the Video PCB. I'm guessing this information is being corrupted further along the data path as it is transferred to or processed within the video PCB. So how does the sprite information progress from the CPU to Video PCB? That task is handled by the 8257 Direct Memory Access (DMA) controller IC which updates the Sprite RAM during vertical blanking.
The DMA controller is configured by the CPU within an interrupt routine, to transfer a block of data from starting address 6900 Hex to the Sprite RAM from address 7000 Hex. This transfer takes place at high speed inbetwen active video frames to avoid flickering or ghosting of the sprites on screen. That could explain the use of higher speed, 2148H-3 ICs for the Sprite RAM with a 55 nanosecond access time compared to 250 - 300 nanoseconds for the more common 2114 RAM used in other parts.
Interestingly, the byte of data which is being corrupted along the way, from address #6900 would be the very first byte in the block to be transferred. So possible causes of the fault symptom might be an out of spec RAM IC which is unable to write the fast transfer data correctly - as only a single bit of data is incorrect that would correspond with the RAM in position 6R, at address 000 - or the data buffer which may be slow to respond to the enable / direction signals and corrupting the first byte in the sequence.
The 74LS08 AND gate in position 5R could also be slow to respond, affecting the enable signals but as the glitch always seems to relate to a single data bit (D6) my guess is the 74LS245 in position 5S is the most likely cause. Looking at those signals with my oscilloscope triggered on the vertical interval period I can't see any with poor transitions or logic levels so I'll take a punt and remove, socket and replace the 74LS245.
I've been tracing a fault on a Donkey Kong TKG4 PCB set which involves a sprite character appearing in an incorrect position rather than being cleared from screen as intended. Not surprisingly the problem appears to be in the area of the Sprite RAM however initial checks using my Donkey Kong RAM testing program indicated the Sprite RAM was working perfectly when written to and read back by the system's Z80 CPU.
It now appears the fault occurs during a high speed DMA transfer of data from the Main to Sprite RAM during each vertical blanking period. The issue could be caused by an out of spec. RAM IC with slower than expected access time, by marginal timing within the surrounding logic components or possibly both. A 'glitch' problem such as this can sometimes be caused by an interaction between components each with slight variations from standard signal levels or response times.
The RAM, type 2148H-3 doesn't appear to be readily available though a few can be obtained from sellers overseas so I'd prefer to replace the more common logic components first in case that changes the fault condition. Although just a single bit (D6) of the very first Sprite RAM address (7000 Hex) seems to be affected any delay in the response of the 74LS245 data buffer or 74LS08 AND gate which controls its direction and output enable signals could be critical.
The 74LS245 seems most likely as a single data bit output could be affected, I have some new ones to hand as well as 20 pin IC sockets so will replace that component and check the result; as below.
Playing the game through to the end of the first level, the girl's head sprite still appeared in the same position but this time seemed to be flickering rather than solid. Although the image on screen looks worse it is actually an improvement as the object should not be appearing in this position at all. In fact from first power on it now seems possible to complete the first level more often without the fault occurring at all.
I should mention that there was originally some intermittent nature to the fault as I was told, and did manage to confirm at least once that the sprite did not always appear in the wrong position in the first pass. That wasn't so easy to prove as I'm not good at this game, it's never been a favourite of mine though I do appreciate its significance and value to collectors. Combine that with the fact that I'm playing with an Atari / Commodore 64 style joystick on a screen that's rotated 90 degrees.
If it had been necessary to quickly return the board to operation rather than learning the reason behind such an unusual symptom I could well have reached this point by simply hitting the components around the sprite RAM area with a bit of freeze spray and observing the symptoms while playing the game. As it now seems almost certain that I will have to order and replace one of the Sprite RAM IC's anyway I'll try that now to confirm whether cooling the RAM prevents the fault from occurring.
Powering the board on again, with symptoms already improved having replaced the buffer IC - playing until the fault symptom is observed then cooling the RAM in position 6R with an occasional gentle squirt of spray - starting a new game without powering the PCBs off the next pass does indeed complete without the fault recurring. That's enough to justify ordering a couple of replacement RAM ICs from overseas.
Searching for the 2148H-3 very few seem available, mostly from the U.S. but postage from U.S. to Australia is always quite expensive and more than the actual components in this case. Looking at the MikesArcade website the HM-6148P-6 is listed as a suitable alternative and very reasonably priced but once again due to the concern over the cost of shipping I'll search for that part and order from a source within our region.
I'm waiting on an order for a replacement RAM IC to correct a sprite glitch in the Donkey Kong PCB set which I have on the bench for repair. I've already replaced a 74LS245 IC which buffers the sprite data as it is transferred from Main to Sprite RAM during each Vertical interval. That did make a slight improvement to the fault symptom, although the data levels looked OK it seems the response time of the data and control signals is critical along with the access time of the RAM IC.
As a precaution and to see if it makes any change to the symptom I'll also replace the 74LS08 in position 5R which handles the enable and direction control signals for the buffer. The original IC is a Fujitsu brand with a date code from 1981, I'm generally suspicious of Fujitsu ICs from the early-mid 1980's which are known for a high failure rate with outputs often going open circuit.
Although this particular IC may be slightly earlier than affected Fujitsu ICs and the outputs are not open circuit I an concerned about any excessive propagation delay or rise time of the output signals. I checked the 74LS08 ICs input and output signals with the oscilloscope, triggering on vertical sync and zooming in on the burst of activity during vertical interval.
The first image, above is the /OBJWR signal as it arrives at the inputs of the 74LS08 from the CPU PCB and below is output pin 3. That's an acceptable signal with good rise times and well within TTL logic levels but there is just a slight rounding of the high level compared to the input signal which has arrived via the interconnecting cable from the CPU PCB. Output pins 6 and 11 of the 74LS08 also have a similar appearance to the image below.
- Nothing to worry about there but just to illustrate the sort of issue I was looking for, the image below shows the output signal from a faulty 74LS08 on a previous repair. (This one was on a Space Invaders PCB).
So even though the 74LS08 appeared to be working correctly, as a precaution I have now replaced it with a new IC. Predictably the fault symptoms appear unchanged but at least I have eliminated the two most likely suspects for the sprite glitch other than the RAM itself.
Interestingly, looking back at the circuit diagram excerpt which I included above; the /OBJRD signal never appears to be active when the game program is running. That is, having transferred sprite data from the main to sprite RAM that data is never read back by the CPU. It is provided for in hardware and does work, with my test program running data is written to the sprite RAM and read back by CPU. In that instance both /OBJWR and /OBJRD signals have activity.
Anyway, in the meantime my order for 2 x HM6148P-6 RAM ICs has arrived but the news is not all good. Although their markings appear genuine the pins have obviously been re-tinned with solder in an attempt to pass them off as 'new' ICs. That isn't a major problem if the parts are genuine, working components of the correct type but is a warning sign that all may not be as it appears. Before trying either in the Donkey Kong PCB set I'll check them using my little CPU / RAM tester setup.
The CPU / RAM tester, fitted with a known working Z80 CPU will also test the functionality of a 2114 or pin compatible RAM IC such as the 6148 with a pass or fail indication on its row of LED indicators. Trying both of the newly acquired ICs, the first one indicates a pass, the other shows a fail with an addressing error. That's a further indication that these ICs were probably untested, in unknown condition and just dressed up to sell as 'new' components.
The IC which passed the RAM test could be a genuine working part (albeit not brand new obviously) so I'll try that one in the Donkey Kong video PCB, removing the original 2148H-3 and installing an 18 pin IC socket.
The result of that is a definite fail with multiple sprite errors, from incorrect positioning to glitchy dropouts and complete disappearance here and there. I'd say although the basic functionality is the same as a 6148 RAM this one is obviously not a high speed component at all and more likely some other 2114 RAM variant which has been re-marked as a 6148. That seems to be an alarming trend, i.e. old second hand components being re-marked as rare or higher spec. types to sell at a premium price...
So, without straying too far off-topic I've ordered another couple of RAM ICs from further afield. These ones are type UM2148-1 with a 55ns access time, which matches the original 2148H-3 and should work perfectly if all goes well.
I've ordered and just received (another) couple of RAM ICs for the Donkey Kong PCB set which I have on the bench. These ones are hopefully genuine, 2148-1 ICs with a 55 nanosecond access time as required for the sprite RAM on the Video PCB. The original RAM had a fault with one memory location causing an unusual symptom but the previous two replacements ordered may not have been genuine, high speed RAM ICs.
Those had general errors and resulted in random, glitchy sprite errors on screen. The latest ones appear genuine and have 1988 date codes, tested and run on the actual PCB. The first seemed fine initially but after a warmup I noticed a few sprite glitches so trying the last remaining component, after a good warmup and several games played all appears to be working perfectly. Whew!.
Obviously the speed of these components is critical to work correctly in the Sprite RAM area on the Donkey Kong video PCB. This seems due to a high speed DMA transfer of the sprite information which takes place during vertical interval, initiated by the 8257 DMA controller IC on the CPU PCB. When tested at normal CPU write and read rates using my Donkey Kong test program as well as the standalone CPU / RAM tester, the original RAM and most of the potential replacements performed correctly with no errors.
So that was a simple RAM fault with a complex explanation. To repair an issue like this, without investigating the exact details should be possible; given the fault had already been isolated to the video PCB, affected the sprites and was apparent after a slight warmup simply observing the symptoms while gently cooling the most likely suspects with some freeze spray would have most likely identified the cause. Having a reliable source for replacement RAM ICs locally would have been a big help!
To be continued...
Web Resources (External Links) -
Donkey Kong (1981 video game) - Wikipedia
Donkey Kong disassembly - furreykef, Github
Donkey Kong MAME driver - dkong.cpp - GitHub
Donkey Kong Memory Map - arcaderestoration.com
Pinout: Nintendo Classic - DK, DK Jr, DK 3, Mario Bros, Popeye - mikesarcade.com
All images and text on this website are Copyright.
Contact: jbtech at telstra dot com