Trying to dump CCE War in the Gulf, CHR bus issues

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Trying to dump CCE War in the Gulf, CHR bus issues

Post by BootGod »

So I'm trying to dump the CCE version of War in the Gulf for someone, but I've run into a snag that has me stumped. 128K PRG / 128K CHR. The mapper chip (TC-112) operation is simple enough, 4 registers as so:

$6000 Load 4K CHR bank to PPU $0000. Lower 2 bits unused (wr bank# << 2).
$6001 Load 2K CHR bank to PPU $1000. Lowest bit unused (wr bank# << 1).
$6002 Load 2K CHR bank to PPU $1800. Lowest bit unused (wr bank# << 1).
$6003 Load 8K PRG bank to $8000

$A000,$C000,$E000 are fixed to the last 3 PRG banks

Mirroring is hard-wired to vertical.

Now for the problem: When trying to read the CHR data, I'm getting some sort of bus interference that mangles the results (random bytes) and it will also "miss" various 256-byte pages of CHR (reads 00 in the areas). The pages it misses seems to be consistent between dumps, but there is no discernible pattern to which pages it misses.

You can even see the corruption in the CopyNES tile viewer, and each time you refresh, the tiles will glitch a little different.

The CHR ROM itself gets 12 degrees F hotter than other chips on the board during operation.

The CHR ROM used is the rather uncommon 28-pin 128K chip with only 1 /CE pin. There is an 74LS00 chip in place to deal with the CHR /RD line, albeit it deals with it kinda strange (from what I've seen). It uses 3 outta 4 NAND gates wired like this:

74LS00

pin 1 (1A): cart CHR /RD line, and pin 5 (2B)
pin 2 (1B): NC
pin 3 (1Y): pin 4 (2A)
pin 4 (2A): pin 3 (1Y), also connected to a 561 ceramic cap to GND
pin 5 (2B): pin 1 (1A) [cart CHR /RD]
pin 6 (2Y): pin 9 (3A), pin 10 (3B)

pin 8 (3Y): to TC-112


Voltage levels going thru this mess:

While the game is playing normally (graphics look good):
cart CHR /RD -> 2.33V -> LS00 -> 0.55V -> TC-112 -> 2.80V -> CHR ROM /CE

While NES is idle (CopyNES slave mode, graphics are off):
cart CHR /RD -> 0.05V -> LS00 -> 4.40V -> TC-112 -> 4.97V -> CHR ROM /CE

While reading CHR ROM (graphics are messed):
cart CHR /RD -> 4.69V -> LS00 -> 0.19V -> TC-112 -> 0.00V -> CHR ROM /CE

I don't have a great understanding of electronics at this level, so I'm unsure of why the voltages differ from when the game is running and when I'm trying to read it. I'm fairly certain this is related to my problem because I sent the plugin I wrote to someone with the Gluk version of War in the Gulf, which uses a normal 32-pin CHR and doesn't have the LS00 and the plugin works just fine for him with no CHR bus issues. The PRG ROM is the same between carts. The CHR probably is too, but I haven't resorted to pulling the ROM to read it manually yet.

Any one have any ideas? I looked thru the game code, nothing jumped at me, but if anyone wants to take a look, PM me and I'll send you the code.
Last edited by BootGod on Fri Oct 29, 2010 8:21 pm, edited 1 time in total.
socram8888

Post by socram8888 »

Dump the CHR-ROM several times and make an average of each bit value. It isn't the best way, but it should work
piteta
Posts: 16
Joined: Fri Dec 16, 2005 12:42 pm
Location: Spain
Contact:

Post by piteta »

Hi, i've opened the two copies of the famicom version i have right now and i was wrong: they don't use the same board as the gluk version, in fact both of them use too the same board yours is using: tc112 + ls00. When i dumped the gluk version (with the help of cah4e3) i also dumped the famicom version and crc's from all chips matched so if your cart is also a famicom cart, then crc should match with the roms i sent you. I know nothing about nes hardware but... ¿could that ls00 used for some kind of copy protection? I also tried what you told me by email with this famicom version and i still get time out errors. Chr rom and ls chip also get a bit hotter than when you're playing.
I also found that i have some scans done for this boards:

http://i25.photobucket.com/albums/c91/p ... ompcbf.jpg
http://i25.photobucket.com/albums/c91/p ... espcbf.jpg
http://i25.photobucket.com/albums/c91/p ... lfpcbd.jpg
http://i25.photobucket.com/albums/c91/p ... lfpcbf.jpg
http://i25.photobucket.com/albums/c91/p ... fopcbd.jpg
http://i25.photobucket.com/albums/c91/p ... fopcbf.jpg

i hope they can help...


[Page-widening images converted to links by MOD]
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

socram8888 wrote:Dump the CHR-ROM several times and make an average of each bit value. It isn't the best way, but it should work
That might work for the random values, but the zero pages peppered about are consistently in there.

piteta, have you tried dumping your FC carts with the plugin I sent you? Considering they use the LS00 as well, it probably wouldn't work. I will post a scan later, but this one is basically the same as your FC one, but it is an actual 72-pin NES board.

I guess it could be a type of copy protection, but I don't see the program doing anything special to avert this behavior.
piteta
Posts: 16
Joined: Fri Dec 16, 2005 12:42 pm
Location: Spain
Contact:

Post by piteta »

Yes, i tried to dump the famicom version with your plugin but chr was corrupted too. About the copy protection, maybe it's made by hardware, although i don't know what to think about it because in the gluk pcb chr /rd line is directly conected to pin 19 on the tc112 (the same pin where the ls chip is conected on the famicom board) :? Btw, i checked what is conected into my ls chip and i found one difference between yours and mine: pin 2 (1B) is connected to pin 1 (1A) and pin 5 (2B)
Enough of your games Asthar, this is between you and me.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Trying to dump CCE War in the Gulf, CHR bus issues

Post by lidnariq »

BootGod wrote:74LS00

pin 1 (1A): cart CHR /RD line, and pin 5 (2B)
pin 2 (1B): NC
pin 3 (1Y): pin 4 (2A)
pin 4 (2A): pin 3 (1Y), also connected to a 541 ceramic cap to GND
pin 5 (2B): pin 1 (1A) [cart CHR /RD]
pin 6 (2Y): pin 9 (3A), pin 10 (3B)
pin 8 (3Y): to TC-112
That's a little weird. I think that LS logic treats unconnected inputs as high, but one's still not supposed to leave inputs floating. (If what piteta says is what should be true here, then this makes more sense to me...)

What this chip is supposed to do is be a pulse spreader or deglitcher -- whenever /CHRRD changes it takes a little while to charge or discharge the capacitor. What happens if you remove that 541 capacitor?
coinheaven
Posts: 280
Joined: Sat Sep 17, 2005 12:26 pm

Post by coinheaven »

this was released on the famicom? what is the famicom title?
piteta wrote:Hi, i've opened the two copies of the famicom version i have right now and i was wrong: they don't use the same board as the gluk version, in fact both of them use too the same board yours is using: tc112 + ls00. When i dumped the gluk version (with the help of cah4e3) i also dumped the famicom version and crc's from all chips matched so if your cart is also a famicom cart, then crc should match with the roms i sent you. I know nothing about nes hardware but... ¿could that ls00 used for some kind of copy protection? I also tried what you told me by email with this famicom version and i still get time out errors. Chr rom and ls chip also get a bit hotter than when you're playing.
I also found that i have some scans done for this boards:

http://i25.photobucket.com/albums/c91/p ... ompcbf.jpg
http://i25.photobucket.com/albums/c91/p ... espcbf.jpg
http://i25.photobucket.com/albums/c91/p ... lfpcbd.jpg
http://i25.photobucket.com/albums/c91/p ... lfpcbf.jpg
http://i25.photobucket.com/albums/c91/p ... fopcbd.jpg
http://i25.photobucket.com/albums/c91/p ... fopcbf.jpg

i hope they can help...


[Page-widening images converted to links by MOD]
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

pin 2 is floating on mine, I double checked. It reads at ~ 1.5V.

I tried removing the cap, it makes the game graphics a bit glitchy while playing. So it seems you are correct on the purpose of this circuit.

It's possible that this circuit has nothing to do with the problem, it just seemed the most suspect to me.
piteta
Posts: 16
Joined: Fri Dec 16, 2005 12:42 pm
Location: Spain
Contact:

Post by piteta »

As you can see on my scans, 1 & 2 are connected with a track. What i can't understand it's why on yours is unconected because that way the truth table is not the same :? Btw, seeing what coinheaven says, there's a another little diference: capacitor on mine is 561. I guess the only think that will change is the time constant but who knows... And well, if it's a deglitgher may be it has to do something with the problems we're having when trying to read chr rom. ¿could it be delaying the read process and the data you read is data you should have read x (micro/nano)seconds before? or may be you read it faster than you should and you give no time to the capacitor to discharge...
coinheaven wrote:this was released on the famicom? what is the famicom title?
All i know is that nes and famicom pcbs for this game exist. Title is the same as the thread: War in the gulf (in spain was released with its name translated: la guerra del golfo)
User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Re: Trying to dump CCE War in the Gulf, CHR bus issues

Post by kevtris »

BootGod wrote:
74LS00

pin 1 (1A): cart CHR /RD line, and pin 5 (2B)
pin 2 (1B): NC
pin 3 (1Y): pin 4 (2A)
pin 4 (2A): pin 3 (1Y), also connected to a 541 ceramic cap to GND
pin 5 (2B): pin 1 (1A) [cart CHR /RD]
pin 6 (2Y): pin 9 (3A), pin 10 (3B)

pin 8 (3Y): to TC-112

Hmm I just drew that circuit out and figured out what it is doing. It is an edge detector, and detects rising edges on /RD. (does it have any kind of IRQs?)

Code: Select all

/RD ----|____|-------|__________|------------

cap ______|----|_______|----------|__________

out _________|-|________________|-|__________
hopefully this drawing will come out. Basically the output of the "mess" will produce a skinny high pulse on the rising edge of /RD only. The first NAND is inverting the input and via the cap causing it to be delayed a little. the second NAND then goes low when both inputs are high, and the final NAND inverts it to give positive pulses.

you might want to try increasing the size of the capacitor so that the pulses are slightly longer. try adding a few hundred PF to it, and tie pins 1 and 2 together. 2 shouldn't be floating, but honestly probably doesn't make much difference since it will read high. I'd say a maximum total of 1000pf would be the highest you'd wanna go. (.001uf)

As for what that pulse DOES, I have no clue and IRQ counting is about the only thing I can think of.
/* this is a comment */
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

piteta wrote:there's a another little diference: capacitor on mine is 561
Oops, it's actually a 561 on mine too (fixed post). I doubt 20pF would change much anyhow.

Kevtris: No IRQ's on this one. I can't verify your drawing, I don't have a scope :( (someday...)

I will give a bigger cap a try this weekend. Although, if the game can manage to work as is, certainly copynes should be able to read it somehow without having to modify the cart, wouldn't you agree?

I whipped up a pinout of the TC-112. Pretty straightforward, though I did encounter something curious. It has a connection to PRG A2 and I don't know why. The code doesn't explicitly use it. I tried poking at it from copynes to see if anything would happen, but nothing that I could tell.

The placement of the PRG A2 pin on the chip itself seems very odd. See for yourself:

Code: Select all

C = Connected to cart
R = Connected to ROM

            ---------  
C       M2 -|1    40|- VCC
CR PRG  D7 -|2    39|- PRG A16 R
CR PRG  D6 -|3    38|- PRG A15 R
CR PRG  D5 -|4    37|- PRG A14 R
CR PRG  D4 -|5  N 36|- PRG A13 R
CR PRG  D3 -|6  T 35|- PRG /CE R
CR PRG  D2 -|7  D 34|- NC
CR PRG  D1 -|8  E 33|- CHR A16 R
CR PRG  A1 -|9  C 32|- CHR A15 R
CR PRG  A0 -|10   31|- CHR A14 R
C  PRG R/W -|11 T 30|- CHR A13 R
C  PRG /CE -|12 C 29|- CHR A12 R
C  PRG A14 -|13 - 28|- CHR A11 R
C  PRG A13 -|14 1 27|- CHR /CE R
C  CHR A13 -|15 1 26|- NC
C  CHR A12 -|16 2 25|- PRG D0  RC
C  CHR A11 -|17   24|- NC
CR CHR A10 -|18   23|- NC
74LS00  3Y -|19   22|- PRG A2  RC   eh?
       GND -|20   21|- NC
            ---------
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

BootGod wrote:The placement of the PRG A2 pin on the chip itself seems very odd.
It might be explainable if the mapper registers selected by A2 were added late in design and used only by games other than this. And even if there is no IRQ, it might be an extra bank select pin for clocking a mid-scanline bankswitch (like MMC2/MMC4?).
User avatar
kevtris
Posts: 504
Joined: Sat Oct 29, 2005 2:09 am
Location: Indianapolis
Contact:

Post by kevtris »

BootGod wrote:
piteta wrote:there's a another little diference: capacitor on mine is 561
Oops, it's actually a 561 on mine too (fixed post). I doubt 20pF would change much anyhow.

Kevtris: No IRQ's on this one. I can't verify your drawing, I don't have a scope :( (someday...)

I will give a bigger cap a try this weekend. Although, if the game can manage to work as is, certainly copynes should be able to read it somehow without having to modify the cart, wouldn't you agree?
Nope, the access pattern is different between the PPU rendering, and manually via prodding 2007. The 2007 pattern is longer than the rendering pattern. Both are run by separate state machines.

The two state machine control signals are simply OR'd together, so bad stuff can happen if you write during rendering. You can trigger the case where the PPU is both reading AND writing at the same time, in fact both /RD and /WR go low!

The whole point of this is 2007 vs. rendering are two very different sets of conditions on the CHR bus so it's possible that it would act different. Interesting that that happened because this is the first case of that being an issue.

Because a 2007 read takes longer, maybe the pulse has to be longer too, to compensate (note: the cart may not run properly any more in render mode but will in 2007 read mode).

HEYYYY what's this?

why, it's "Fighting hero" by ntdec! I found I have a cart with the TC-112 on it too. There's 4 chips on this board. And interestingly enough, there's no capacitor.

the chips are marked: ND946-P-UN (prg), ND947-C1 (CHR), and ND947-C2-V (CHR) and of course TC-112.

the PCB is marked "TH2219-2" if that helps. Let me verify the pinout with yours real fast.

changes:
pin 19 - directly connects to CHR /RD
pin 26 - connects to /CE on CHR ROM 2
pin 27 - connects to /CE on CHR ROM 1 (this is like your cart shown for clarity)
pin 34 is doubtlessly for a PRG ROM which would map first (you always want the first rom in the uppermost bank so pin 35 has to be ROM2)


soo maybe you can try bypassing the 7400 circuit all together and run /RD directly into pin 19 like on this board. can't hurt I guess.
/* this is a comment */
BootGod
Posts: 359
Joined: Wed Jul 13, 2005 3:14 pm

Post by BootGod »

Ok, I tried a few different capacitors, it didn't seem to have an effect. Connecting CHR /RD directly pin 19 did make a significant improvement, it completely got rid of the "zero pages", but the tiles were still glitching, and this time also in render mode. I tried jumping it with a cap (forget exactly what I tried, it was ballpark of the 561 though).

I think the glitching now is the same between rendering and reading from 2007, so if one was able to correct it, I think it would be both playable and readable via copynes.

It appears that on piteta's gluk cart, CHR /RD is also directly connected to pin 19 with nothing in between.
piteta
Posts: 16
Joined: Fri Dec 16, 2005 12:42 pm
Location: Spain
Contact:

Post by piteta »

that's right: on gluk's pcb tc112 is directly conected to the cart connector.
Enough of your games Asthar, this is between you and me.
Post Reply