Double Dragon corrupted picture

[aapuzzo]

Solved - To anybody that may ever see this thread. The primary issue was caused by cold solder joints at IC36 SN74LS25N logic chip. I also had bad PCM sound chip M5205 which causes popping on some sounds. There is good information below on the troubleshooting involved in fixing it.

I just purchased a broken Double Dragon board from Ebay because I want to get into fixing arcade boards. I have a bunch of experience with consoles and most of the tools to do it. This is the first arcade board I ever attempted This board looks very clean and the seller said the problem is on the Jamma PCB because it was tested with a working set. What should I try next? I'm looking for broken traces while waiting for suggestions. I extracted the code from the roms circled in reg and replaced the files for those chips in the DDRAGON.ZIP MAME rom and boots as expected in MAME.

 

[Darksoft]

Hello!

welcome to the arcade repair world! First thing, I highly encourage you to check that the roms that you have are not in MAME. This is very simple to do, just open a CMD window and run mame with the file name that you want to check as parametere1 and give -romident as parameter 2. That will help you understand if your eproms are already dumped or not and if they are good. Some times you may have a bitrot and that will help you identify it.

i.e. mame.exe myfile01.bin -romident

Having said that, next thing I'd check would be the 68000 CPU. Make sure that it has a valid clock signal going in and that the address and data pins are oscillating correctly. If some of the address bits are stuck, that means that the code is in a loop and probably waiting for something that never happens.

Next, you can check the 74LS chips. If they are Fucjitsu, you can already suspect those as the culprit.

Check also for scratches or clear cold solders, etc. My guess is that some logic chips (aka 74LS) have gone south.

 

[aapuzzo]

Hello!

welcome to the arcade repair world! First thing, I highly encourage you to check that the roms that you have are not in MAME. This is very simple to do, just open a CMD window and run mame with the file name that you want to check as parametere1 and give -romident as parameter 2. That will help you understand if your eproms are already dumped or not and if they are good. Some times you may have a bitrot and that will help you identify it.

i.e. mame.exe myfile01.bin -romident

Having said that, next thing I'd check would be the 68000 CPU. Make sure that it has a valid clock signal going in and that the address and data pins are oscillating correctly. If some of the address bits are stuck, that means that the code is in a loop and probably waiting for something that never happens.

Next, you can check the 74LS chips. If they are Fucjitsu, you can already suspect those as the culprit.

Check also for scratches or clear cold solders, etc. My guess is that some logic chips (aka 74LS) have gone south.

Thank you for the reply. This is my first day trying rom dumping. I actually checked the roms using this site https://romident.coinopflorida.com/ and they all came up valid Double Dragon ROMS on the Jamma PCB before replacing them in my MAME romset. There was one small MB7114H brom I couldn't test. I'll get a printout with the method you described.

https://romident.coinopflorida.com/

 

[aapuzzo]

I just used the method you suggested by only zipping the ROMs I dumped from the photo I attached in my initial post minus the MB7114H chip I can't dump. I think they look good. I ordered a logic testing prob from Amazon and it should be here later today. I also have an oscilloscope if somebody could tell where where to connect it.

 

[Darksoft]

There was one small MB7114H brom I couldn't test. I'll get a printout with the method you described.

That is for the color output. Shouldn't be related to your issue, which apparently is frozen screen with bad GFX. Obviously GFX are bad, because the CPU is not doing what it should and not telling properly to the graphic part what should be shown on screen.

I just used the method you suggested by only zipping the ROMs I dumped from the photo I attached in my initial post minus the MB7114H chip I can't dump. I think they look good.

Looks good.

I ordered a logic testing prob from Amazon and it should be here later today. I also have an oscilloscope if somebody could tell where where to connect it.

Good news. Oscilloscope or Logic Analyzer? Osciloscope has usually only 1 input and is analog. You can check your Clock with this one. the voltage levels (LO /HI), you can check with the probe.

 

[nnap]

Check the reset signal on the M68000 once you get the logic probe. It is pin 18. put the probe on that pin and turn on the board. The state should change shortly after you turn on power. So it will start in one state and after a second or so it will change. If it does that, the CPU will start and try to execute the code. If it does not, you have to check the reset circuit.

 

[aapuzzo]

Good news. Oscilloscope or Logic Analyzer? Osciloscope has usually only 1 input and is analog. You can check your Clock with this one. the voltage levels (LO /HI), you can check with the probe.

I have a Siglent 1104X-E Oscilloscope 4Channel 200MHz which I think can do logic analyzing but it needs an attachment that was expensive if I remember correctly (I was afraid I wouldn't be able to figure out how to use it.). I "have" the license already added for the feature I'm pretty sure. I used it only once to fix the controller ports on a jaguar.

Check the reset signal on the M68000 once you get the logic probe. It is pin 18. put the probe on that pin and turn on the board. The state should change shortly after you turn on power. So it will start in one state and after a second or so it will change. If it does that, the CPU will start and try to execute the code. If it does not, you have to check the reset circuit.

Thanks I'll try this when I get back from work and post result.

 

[ack]

You could also try https://github.com/jwestfall69/ddragon-diag (also check out the docs directory, there is a lot of info in there). I wrote that a few years ago.

 

[aapuzzo]

Ok something weird happened. I was attempting to try the logic test with pin 18 and plugged the Supergun in with the probe touching. This being awkward and by myself the power plug connected and lost connection a few times in rapid succession, the game screen changed colors a few times and I could hear the complete theme song on loop. After further testing and trying to get it to repeat I noticed it does a different pattern each time I quickly restart the board. I heard the full intro animation where Mary gets punched one time as well and it started the theme song. Could I have a partially failed eprom chip? I'm going to try burning the test code ack suggested. It seems I can only repeat this if I do the quick power cycle.

 

[ack]

There is a dedicated sound cpu (a lot of arcade board have this) on the board. The (one-way) communication between the main cpu to the sound cpu is done via a latch (1 byte). Where the main cpu writes a byte to the latch then triggers an interrupt on the sound cpu, which then reads the latch/byte. The byte is used by the sound cpu to determine what PCM (2x eproms near the sound amp) or FM (ym2151) it should play. Your fast powercycle is likely putting the board in the weird state where there is garbage on the latch and at the same time triggering a bogus interrupt on the sound cpu.

I guess the good news is your sound cpu/subsystem seems to be working.

 

[aapuzzo]

There is a dedicated sound cpu (a lot of arcade board have this) on the board. The (one-way) communication between the main cpu to the sound cpu is done via a latch (1 byte). Where the main cpu writes a byte to the latch then triggers an interrupt on the sound cpu, which then reads the latch/byte. The byte is used by the sound cpu to determine what PCM (2x eproms near the sound amp) or FM (ym2151) it should play. Your fast powercycle is likely putting the board in the weird state where there is garbage on the latch and at the same time triggering a bogus interrupt on the sound cpu.

I guess the good news is your sound cpu/subsystem seems to be working.

I put the test rom in as instructed and sometimes I get 7 of what appears to be coin insert sounds and one higher pitched shorter sound. This code runs most of the time. A few times I just got the one higher pitched short sound after a longer delay like it tried to play the coin sounds first. The screen is solid green sometimes and others I get a few white characters. I will say the image isn't always static like I originally thought. When the board decides to work it may change a few frames. What should I try next?

 

[ack]

The diag rom will provide a beep code when it detects an issue.

https://github.com/jwestfall69/ddragon-diag/blob/main/docs/error_codes.md

Based on what you said it sounds like the beep code was 0000 0001, which is dead output from the work ram (which is also the ram used for the foreground tiles, ie: text).

The data path from the CPU to the work ram is

CPU (IC41) <=> 74LS245 (IC12) <=> 74LS245 (IC36) <=> Work RAM (IC21)

The normal behavior of a 74LS245 if its enabled but its input pins have no signal will be to output high on all of its outputs pin. The test that triggers that error code writes 0x00 then reads back the result for each of the first 256 bytes of work ram. If the reads all comes back as 0xff its assume either the 74LS245@IC36 or RAM@IC21 are not outputting any data when asked and triggers the error. I suppose its also possible the ram chip is bad and always outputting 0xff.

In this case I would use the logic probe and verify the following things when you power on the board with the diag rom
- verify activity on the enable pins of IC36 and IC21
- verify activity on the direction pin of IC36

The activity will be short lived as the diag rom will do those 256 write/reads then error out and not touch ram anymore.

 

[aapuzzo]

The diag rom will provide a beep code when it detects an issue.

https://github.com/jwestfall69/ddragon-diag/blob/main/docs/error_codes.md

Based on what you said it sounds like the beep code was 0000 0001, which is dead output from the work ram (which is also the ram used for the foreground tiles, ie: text).

The data path from the CPU to the work ram is

CPU (IC41) <=> 74LS245 (IC12) <=> 74LS245 (IC36) <=> Work RAM (IC20)

The normal behavior of a 74LS245 if its enabled but its input pins have no signal will be to output high on all of its outputs pin. The test that triggers that error code writes 0x00 then reads back the result for each of the first 256 bytes of work ram. If the reads all comes back as 0xff its assume either the 74LS245@IC36 or RAM@IC20 are not outputting any data when asked and triggers the error. I suppose its also possible the ram chip is bad and always outputting 0xff.

In this case I would use the logic probe and verify the following things when you power on the board with the diag rom
- verify activity on the enable pins of IC36 and IC20
- verify activity on the direction pin of IC36

The activity will be short lived as the diag rom will do those 256 write/reads then error out and not touch ram anymore.

Thank you so much for the reply. I'll try this when I get home. I have to learn how to figure out how to read a schematic and learn what "enable" pins are. When you say possible bad ram chip are you talking about the eprom IC20 (21j-5 27C256) or a different chip? If it's even suspect I can easily make another one of those and replace it. I bought a bunch of spare eproms when I decided to take on this project.

 

[Darksoft]

The diag rom will provide a beep code when it detects an issue.

https://github.com/jwestfall69/ddragon-diag/blob/main/docs/error_codes.md

Based on what you said it sounds like the beep code was 0000 0001, which is dead output from the work ram (which is also the ram used for the foreground tiles, ie: text).

The data path from the CPU to the work ram is

CPU (IC41) <=> 74LS245 (IC12) <=> 74LS245 (IC36) <=> Work RAM (IC20)

The normal behavior of a 74LS245 if its enabled but its input pins have no signal will be to output high on all of its outputs pin. The test that triggers that error code writes 0x00 then reads back the result for each of the first 256 bytes of work ram. If the reads all comes back as 0xff its assume either the 74LS245@IC36 or RAM@IC20 are not outputting any data when asked and triggers the error. I suppose its also possible the ram chip is bad and always outputting 0xff.

In this case I would use the logic probe and verify the following things when you power on the board with the diag rom
- verify activity on the enable pins of IC36 and IC20
- verify activity on the direction pin of IC36

The activity will be short lived as the diag rom will do those 256 write/reads then error out and not touch ram anymore.

Master class @ack

 

[ack]

Thank you so much for the reply. I'll try this when I get home. I have to learn how to figure out how to read a schematic and learn what "enable" pins are. When you say possible bad ram chip are you talking about the eprom IC20 (21j-5 27C256) or a different chip? If it's even suspect I can easily make another one of those and replace it. I bought a bunch of spare eproms when I decided to take on this project.

Sorry I typo'd the IC number for the ram chip, its actually IC21. I corrected my original post in case someone else reads it, so they don't get confused.

re: enable pins. There are a numerous components on the board the CPU needs to interact with (rams, roms, etc), but it can only interact with one component at a time (or stuff breaks). The enable pin(s) are used to let the component know the CPU is trying to interact with it. There is usually logic outside of the CPU that will determine which of those components get enabled and is based on what address range the CPU is trying to access. For example this is the memory map (from mame) for double dragon.

]

void ddragon_state::base_map(address_map &map)
{
    map(0x0000, 0x0fff).ram().share("rambase");
    map(0x1000, 0x11ff).ram().w(m_palette, FUNC(palette_device::write8)).share("palette");
    map(0x1200, 0x13ff).ram().w(m_palette, FUNC(palette_device::write8_ext)).share("palette_ext");
    map(0x1800, 0x1fff).ram().w(FUNC(ddragon_state::fgvideoram_w)).share(m_fgvideoram);
    map(0x2000, 0x21ff).rw(FUNC(ddragon_state::comram_r), FUNC(ddragon_state::comram_w)).mirror(0x0600);
    map(0x2800, 0x2fff).ram().share(m_spriteram);
    map(0x3000, 0x37ff).ram().w(FUNC(ddragon_state::bgvideoram_w)).share(m_bgvideoram);
    map(0x3800, 0x3800).portr("P1");
    map(0x3801, 0x3801).portr("P2");
    map(0x3802, 0x3802).portr("EXTRA");
    map(0x3803, 0x3803).portr("DSW0");
    map(0x3804, 0x3804).portr("DSW1");
    map(0x3809, 0x3809).writeonly().share(m_scrollx_lo);
    map(0x380a, 0x380a).writeonly().share(m_scrolly_lo);
    map(0x380b, 0x380f).rw(FUNC(ddragon_state::interrupt_r), FUNC(ddragon_state::interrupt_w));
    map(0x8000, 0xffff).rom();
}

So if the cpu is trying to access any address between 0x2800 to 0x2fff, it will cause the spriteram to be enabled while all the other components would be disabled.

On ROM and RAM chips there are (always?) going to be 2 pins associated with the chip being enabled. The OE (output enable) and CE (Chip enable). Both of these must be low for the chip to be enabled. Its not uncommon for one of those pins to just be tied to ground. A 74LS245 has a single enable pin, which also must be low for it to be enabled.

 

[aapuzzo]

Sorry I typo'd the IC number for the ram chip, its actually IC21. I corrected my original post in case someone else reads it, so they don't get confused.

re: enable pins. There are a numerous components on the board the CPU needs to interact with (rams, roms, etc), but it can only interact with one component at a time (or stuff breaks). The enable pin(s) are used to let the component know the CPU is trying to interact with it. There is usually logic outside of the CPU that will determine which of those components get enabled and is based on what address range the CPU is trying to access. For example this is the memory map (from mame) for double dragon.

]

void ddragon_state::base_map(address_map &map)
{
    map(0x0000, 0x0fff).ram().share("rambase");
    map(0x1000, 0x11ff).ram().w(m_palette, FUNC(palette_device::write8)).share("palette");
    map(0x1200, 0x13ff).ram().w(m_palette, FUNC(palette_device::write8_ext)).share("palette_ext");
    map(0x1800, 0x1fff).ram().w(FUNC(ddragon_state::fgvideoram_w)).share(m_fgvideoram);
    map(0x2000, 0x21ff).rw(FUNC(ddragon_state::comram_r), FUNC(ddragon_state::comram_w)).mirror(0x0600);
    map(0x2800, 0x2fff).ram().share(m_spriteram);
    map(0x3000, 0x37ff).ram().w(FUNC(ddragon_state::bgvideoram_w)).share(m_bgvideoram);
    map(0x3800, 0x3800).portr("P1");
    map(0x3801, 0x3801).portr("P2");
    map(0x3802, 0x3802).portr("EXTRA");
    map(0x3803, 0x3803).portr("DSW0");
    map(0x3804, 0x3804).portr("DSW1");
    map(0x3809, 0x3809).writeonly().share(m_scrollx_lo);
    map(0x380a, 0x380a).writeonly().share(m_scrolly_lo);
    map(0x380b, 0x380f).rw(FUNC(ddragon_state::interrupt_r), FUNC(ddragon_state::interrupt_w));
    map(0x8000, 0xffff).rom();
}

So if the cpu is trying to access any address between 0x2800 to 0x2fff, it will cause the spriteram to be enabled while all the other components would be disabled.

On ROM and RAM chips there are (always?) going to be 2 pins associated with the chip being enabled. The OE (output enable) and CE (Chip enable). Both of these must be low for the chip to be enabled. Its not uncommon for one of those pins to just be tied to ground. A 74LS245 has a single enable pin, which also must be low for it to be enabled.

This is incredible information. I'm a guy that typically fixes things with my soldering skills over diagnosing skills for consoles (just start replacing things). I'm trying to up my game. I thought you meant a different chip which was why I asked. I have a feeling it's ram issue so I will try and purchase another chip while I start following your instructions and testing. I'll report back later.

 

[ack]

Be sure to also double check 0000 0001 is the beep code you are getting. Everything I provided is kinda based on it being that.

 

[aapuzzo]

I'm definitely getting 7 beeps and 1 different one 90% of the time. Sometimes nothing happens so I could have multiple problems. For what it is worth for the 74LS245 ICs you mentioned aren't socketed and the ones next to them are. Somebody probably already replaced them for a reason. Are these the correct replacement parts below? I already ordered another CPU from EBay days ago same part number. I think the AS6C6264-55PCN replacement part is just faster and with memory you can go faster if I am not mistaken. Does the N at the end of SN74LS245N matter? I'll order a bunch of these because the wrestlefest board I am going to work on uses them too.

original
HM6246ALP-10
https://www.alldatasheet.com/datasheet-pdf/pdf/127524/HITACHI/HM6264ALP-10.html
Replacement
AS6C6264-55PCN
https://www.digikey.com/en/products/detail/alliance-memory,-inc./AS6C6264-55PCN/4234595?utm_adgroup=&utm_source=google&utm_medium=cpc&utm_campaign=PMax Shopping_Product_Medium ROAS Categories&utm_term=&utm_content=&utm_id=go_cmp-20223376311_adg-_ad-__dev-c_ext-_prd-4234595_sig-CjwKCAjw2dG1BhB4EiwA998cqFYoqWhiPsh2DAEVv7EaOLTtM_qOjEOehvbXnGMuXw0uDtZtbaohBBoC17oQAvD_BwE&gad_source=1&gclid=CjwKCAjw2dG1BhB4EiwA998cqFYoqWhiPsh2DAEVv7EaOLTtM_qOjEOehvbXnGMuXw0uDtZtbaohBBoC17oQAvD_BwE


SN74LS245
Replacement
SN74LS245N
https://www.digikey.com/en/products/detail/texas-instruments/SN74LS245N/277301?utm_adgroup=&utm_source=google&utm_medium=cpc&utm_campaign=PMax Shopping_Product_Medium ROAS Categories&utm_term=&utm_content=&utm_id=go_cmp-20223376311_adg-_ad-__dev-c_ext-_prd-277301_sig-CjwKCAjw2dG1BhB4EiwA998cqBP1babnbpTh6mFNJT-GBrIGXHye4Tm4HhGU7eGq6gFcRzImao0KNBoCrkIQAvD_BwE&gad_source=1&gclid=CjwKCAjw2dG1BhB4EiwA998cqBP1babnbpTh6mFNJT-GBrIGXHye4Tm4HhGU7eGq6gFcRzImao0KNBoCrkIQAvD_BwE

 

[ack]

Those seem ok to me. Looking over the datasheet for the ram it has 3 enable related pins, so be sure to look at the truth table in the datasheet about what state they each need to be in to enable to chip. I don't think the "N" means anything.

You really should use the logic probe to see if the ram/245 are even getting enabled. Otherwise you could end up swapping them when the issue is upstream in the logic that should be enabling them.

I kinda have a diag rom for wrestlefest too. Its one of the boards I've been using as part of experiment I've been working on called "mad" (multiple arcade diagnostic). The goal is to create a framework to make it eaiser to spin up new diag roms for random arcade boards.

https://github.com/jwestfall69/mad/

I don't have anything setup at the momment to autocompile and provide a zip with the rom files. I can provide you with a copy of the wrestlefest diag roms when/if you want them.

 

[aapuzzo]

Those seem ok to me. Looking over the datasheet for the ram it has 3 enable related pins, so be sure to look at the truth table in the datasheet about what state they each need to be in to enable to chip. I don't think the "N" means anything.

You really should use the logic probe to see if the ram/245 are even getting enabled. Otherwise you could end up swapping them when the issue is upstream in the logic that should be enabling them.

I kinda have a diag rom for wrestlefest too. Its one of the boards I've been using as part of experiment I've been working on called "mad" (multiple arcade diagnostic). The goal is to create a framework to make it eaiser to spin up new diag roms for random arcade boards.

https://github.com/jwestfall69/mad/

I don't have anything setup at the momment to autocompile and provide a zip with the rom files. I can provide you with a copy of the wrestlefest diag roms when/if you want them.

I'm definitely going to check first after I eat dinner. I don't mind having the spare parts and I'm too impatient to wait until Monday if I end up needing them.