What's new
By:

Double Dragon corrupted picture

OK I'm not really sure if I am doing this right but here it goes.

IC21 - AS6C626
When power is plugged in I see 0 pulses/changes with any of the below states - You mentioned "3" Enable related pins is one of these not Enable?
PIN 20 CE# = LOW
PIN 22 OE# = LOW
PIN 26 CE2 = HIGH
PIN 27 WE# = HIGH

IC36 - 74LS245
When power is turned on I see no change from below
PIN 19 OE = HIGH

IC12 - 74LS245 - Has a socket so possibly already replaced?
It comes on as high and and pulses low for a 1000th of a second
PIN 19 OE = HIGH

Does this help at all? Since IC 21 is further down the line and it pulses low is it not staying on because IC 36 isn't working? I can add a socket right now if it needs to be changed and swap it with IC37 which wasn't part of this test. That one has a socket already installed well.
 

Attachments

  • Double Dragon - 3.jpg
    Double Dragon - 3.jpg
    249.7 KB · Views: 47
Last edited:
ack said:
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.

]
Code: 
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.
Click to expand...
Master class COMBO @ack
 
  • Like
Reactions: ack
aapuzzo said:
IC21 - AS6C626
When power is plugged in I see 0 pulses/changes with any of the below states - You mentioned "3" Enable related pins is one of these not Enable?
PIN 20 CE# = LOW
PIN 22 OE# = LOW
PIN 26 CE2 = HIGH
PIN 27 WE# = HIGH
Click to expand...

I just double checked on a board I have
  • PIN 20 is tied to GND
  • PIN 26 is tied to VCC
PIN 22 is the only one that matters in this case and it should not be 100% LOW like that. That would mean the chip is enabled 100% of the time. This points to an issue from where ever that signal is coming from. It will likely be coming from some 74 series logic chip on the board. You can use the schematic and/or multi meter to track down what chip it is. Then use the datasheet for that logic chip and your logic probe to figure out if its acting correctly or perhaps there is an issue with one of its inputs (ie cut trace). Its also possible the issue is not that chip but something upstream from it.

WE is for write enable, when its low the the ram chip will write whatever is on the data bus into its memory.


aapuzzo said:
IC36 - 74LS245
When power is turned on I see no change from below
PIN 19 OE = HIGH
Click to expand...

This may also be getting effected by whatever is causing the ram OE issue.

aapuzzo said:
IC12 - 74LS245 - Has a socket so possibly already replaced?
It comes on as high and and pulses low for a 1000th of a second
PIN 19 OE = HIGH
Click to expand...
This is basically is acting as the gateway for the CPU to talk to all of the components on the board (except for the program roms, which connect directly to the CPU). This includes the CPU being able to send data to the sound CPU via that latch I mentioned before. Since you are getting beep codes it means this IC is working correctly.
 
Well I did something really dumb and by accidented burnt a trace between the cap ground and IC 1 because my hand slipped. I was able to probe it prior to doing that. It had some dead pins before my mess up. After fixing the trace it was restored to the same operation it was before. Now back to trying to actually fix something. I'm going to add a socket to IC1 and replace it unless you say look somewhere else. Half of these on the board have been replaced and are socketed already. I'm annoyed I didn't buy these yesterday. They were in my cart but Digikey was down so I reordered without them at Mouser. The similar chips like this next to it such as IC2 even seem to have some data running on them READ HL with both lights on at the same time.

IC1
74F157N
Pin 1 = H
Pin 2 = LH
Pin 3 = H
Pin 4 = H
Pin 5 = H
Pin 6 = H
Pin 7 = H
Pin 8 = L
Pin 9 = L that goes to pin22 IC21
Pin 10 = L
Pin 11 = L
Pin 12 = H
Pin 13 = Dead
Pin 14 = Dead
Pin 15 = L
Pin 16 = H
 
Last edited:
Actually now that I read the schematic maybe the dead pins aren't used. I'll wait to hear your opinion
 

Attachments

  • Double Dragon - 4.jpg
    Double Dragon - 4.jpg
    195.8 KB · Views: 38
I may be learning something finally. If I don't see that oscillating data coming in that would be why the multiplexer isn't doing anything? If pin 15 is Active L that means it should be enabled because pin 15 goes to ground and reads low? Pin 2 may have a tiny bit of data coming in and does show LH now that I look closer. Updating my other post.
 
Last edited:
So its a truth table and I care about Pin 9 Zd.

If
pin 1 S = H
Pin 15 (E)nable to ground (the one I cooked earlier) = low
Pin 10 l0d = L
Pin 11 l1d = L

So I guess I need to find out why l1d pin 11 doesn't go high and trace back from there? If I saw a different result to the truth table is that when I would assume the chip is bad? Am I actually understanding this?
 

Attachments

  • Double Dragon - 5.jpg
    Double Dragon - 5.jpg
    43.3 KB · Views: 35
Last edited:
Are you doing these pin reading with that update rom thats constantly reading memory? I would be more suspect the issue is with input on pin 1 always being high. If you check the schematics its also connects to the OE pin of IC36. That would need to be low for data to pass between the ram and the CPU.
 
ack said:
Are you doing these pin reading with that update rom thats constantly reading memory? I would be more suspect the issue is with input on pin 1 always being high. If you check the schematics its also connects to the OE pin of IC36. That would need to be low for data to pass between the ram and the CPU.
Click to expand...
I just checked and all of the chips down the row such as ic2 ic3 stay H on pin 1. Pins 10 and 11 on those sound like they have data. The probe makes a more buzzing sound and the HL lights are both lit up when testing those. I don't know if that matters or helps. I'm doing these readings with the diagnostic rom you made. Do you want me to put the original back in?
 
aapuzzo said:
I just checked and all of the chips down the row such as ic2 ic3 stay H on pin 1. Pins 10 and 11 on those sound like they have data. The probe makes a more buzzing sound and the HL lights are both lit up when testing those. I don't know if that matters or helps. I'm doing these readings with the diagnostic rom you made. Do you want me to put the original back in?
Click to expand...
I would use this rom from above

ack said:
This should help make it easier to logic probe the issue.

https://www.mvs-scans.com/misc/ddragon-diag-aapuzzo1.bin

It will just sit there trying to read from work ram.
Click to expand...


If pin 1 on IC1 is stuck high I would work your way backwards. The schematic says its the *RAM signal. The source of which seems to be coming that first page of the schematic.
 
I'll replace IC36 when I get back home. It's the only chip on the board that shows any corrosion. I'll look at the logic table first though. There is oscillating data coming into it.
 
Yeah I'm definitely replacing it. I thought a few pins were dead the corrosion is so heavy. It will be a few hours. I can inspect underneath it too.
 
I'm struggling reading the schematic a little bit right now trying to figure out where IC36 runs but most of the pins on the right sides of IC36 and IC 35 are dead (Pins 11-20}. It looks like the pins on the right side of IC36 run to IC12 if I am doing this right. Every pin on IC12 goes either high, low, or both. No dead pins. If this is the case it's not making it to IC36. The problem I am having is figuring out how the numbers on the chips correspond to the lines and pins. I think the inside numbers (the ones closer to the chip represent the pin and are drawn above the line. The outside numbers I think are used because everything consolidates down to one line to make it easier to draw. I can't tell if these numbers are above or below the line.
 
Last edited:
I figured out how to read it. pins are represented above the line and the secondary number is below the line next to the diagonal and I follow it to the second schematic. There is definitely a break somewhere. The 2-9 pins of IC12 go to the 11-18 pins of IC 36. Just not in the same order. Regardless none of them should read dead if all pins of IC12 give a reading. I think this has to have something to do with the problem. I'm not going to map them all out right now. I'll take the chip out and make sure there are no breaks under it since I see corrosion on the pins. I validated I was reading it correct by checking the pins on IC 36 that had a reading with a continuity tester while off.

The short answer I should be able to put a continuity probe on those pins and run it around the other chip and get something.
 
Last edited:
When a 74LS245's enable pin is high it will not drive the output pins, so they will be dead.
 
We got it!!! Must have just been cold solder joints. When I pulled the chip I had continuity on all those pins. So far it's upside down and all the sprites look like they are there. It's upside down which maybe a dip switch?? and a tiny bit of popping on audio some audio. I can record that if needed. It must have been cold solder joints because I expected corrosion under IC36 but it was perfect.

Remaining issues some popping once in a while and upside down which I am reading the dips right now. Unless this is just an upside down game.
 

Attachments

  • Double Dragon - 6.jpg
    Double Dragon - 6.jpg
    120.5 KB · Views: 42
  • Double Dragon - 7.jpg
    Double Dragon - 7.jpg
    140 KB · Views: 42
There is a dip switch that will rotate the screen to be upright.
 
You must log in or register to reply here.
Back
Top