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

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Trying to dump CCE War in the Gulf, CHR bus issues
by on (#69181)
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.

by on (#69193)
Dump the CHR-ROM several times and make an average of each bit value. It isn't the best way, but it should work

by on (#69202)
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/piteta/nes/gulffamicompcbf.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/gulfnespcbf.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Warinthegulfpcbd.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Warinthegulfpcbf.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Laguerradelgolfopcbd.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Laguerradelgolfopcbf.jpg

i hope they can help...


[Page-widening images converted to links by MOD]

by on (#69203)
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.

by on (#69205)
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)
Re: Trying to dump CCE War in the Gulf, CHR bus issues
by on (#69219)
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?

by on (#69231)
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/piteta/nes/gulffamicompcbf.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/gulfnespcbf.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Warinthegulfpcbd.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Warinthegulfpcbf.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Laguerradelgolfopcbd.jpg
http://i25.photobucket.com/albums/c91/piteta/nes/Laguerradelgolfopcbf.jpg

i hope they can help...


[Page-widening images converted to links by MOD]

by on (#69233)
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.

by on (#69237)
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)
Re: Trying to dump CCE War in the Gulf, CHR bus issues
by on (#69244)
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:
/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.

by on (#69275)
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:
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
            ---------

by on (#69279)
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?).

by on (#69297)
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.

by on (#69304)
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.

by on (#69315)
that's right: on gluk's pcb tc112 is directly conected to the cart connector.

by on (#69316)
Kevtris, I'm glad you mentioned you found this chip in Fighting Hero, which I guess is mapper 193. War in the Gulf can also use this mapper number fine. So the game already works in Nestopia and possibly other emulators.

by on (#69368)
BootGod wrote:
Kevtris, I'm glad you mentioned you found this chip in Fighting Hero, which I guess is mapper 193. War in the Gulf can also use this mapper number fine. So the game already works in Nestopia and possibly other emulators.

Will you share that rom?

by on (#69372)
Wave wrote:
Will you share that rom?

Avast ye. There be no infringin' on this ship.

by on (#69373)
BootGod wrote:
Kevtris, I'm glad you mentioned you found this chip in Fighting Hero, which I guess is mapper 193. War in the Gulf can also use this mapper number fine. So the game already works in Nestopia and possibly other emulators.


good to know for if/when I dump mine.

OK, I had another thought about this cart. is it possible that they are using a single enable ROM and the edge detector is so they don't need to use the CHR /CE line?

is it possible they are only using /RD to enable the ROM? I think on fighting hero they are using two single enable CHR ROMs though... so maybe that's not it. It sure is odd.

The other option is the CHR ROM was too slow or too fast and that was their hack to get it fixed. one of those "oh hell, those 10000000 ROMs we ordered don't work! what do we do?" type of things.

One clue the ROM isn't fully happy is you said it gets quite a bit hotter than the other chips. maybe this is due to some lingering bus conflicts?

---

A followup... I think I figured it out. Looking over the previous stuff in the thread, I suspect that the CHR ROM miight have a positive enable on it. why they didn't just invert /CE to it though I dunno. But it's a possibility. The disablement at the end of /RD would theoretically be to allow for the ALE event to latch the address from D to A0-7 and/or to read the nametables

by on (#69374)
tepples wrote:
Wave wrote:
Will you share that rom?

Avast ye. There be no infringin' on this ship.

And what infringement would be that?

by on (#69375)
@Wave: Distributing a ROM image of a copyrighted video game without permission and without some other defense under copyright law infringes the copyright in that game. See policies #3.

Or perhaps I misunderstood what you meant by "that rom".

by on (#69378)
tepples wrote:
@Wave: Distributing a ROM image of a copyrighted video game without permission and without some other defense under copyright law infringes the copyright in that game. See policies #3.

Or perhaps I misunderstood what you meant by "that rom".

Question is, is it copyrighted?

by on (#69381)
Again, it depends on exactly what you meant by "it" or "that rom". All original works of authorship are copyrighted from the moment they are first fixed in a tangible medium.

by on (#69384)
tepples wrote:
Again, it depends on exactly what you meant by "it" or "that rom". All original works of authorship are copyrighted from the moment they are first fixed in a tangible medium.

Mmm, I thought it had to be registered or something, my fault.

by on (#69385)
tepples wrote:
@Wave: Distributing a ROM image of a copyrighted video game without permission and without some other defense under copyright law infringes the copyright in that game. See policies #3.

Or perhaps I misunderstood what you meant by "that rom".


- Since it mentions "CCE", it sold lots of such 60-pin black cartridges in Brazil (199X), by altering or erasing the original developer. Example: "Rock Man 2" had the CAPCOM words replaced by NTDEC. ;)

by on (#69390)
kevtris wrote:

OK, I had another thought about this cart. is it possible that they are using a single enable ROM and the edge detector is so they don't need to use the CHR /CE line?

is it possible they are only using /RD to enable the ROM? I think on fighting hero they are using two single enable CHR ROMs though... so maybe that's not it. It sure is odd.

The other option is the CHR ROM was too slow or too fast and that was their hack to get it fixed. one of those "oh hell, those 10000000 ROMs we ordered don't work! what do we do?" type of things.

One clue the ROM isn't fully happy is you said it gets quite a bit hotter than the other chips. maybe this is due to some lingering bus conflicts?

---

A followup... I think I figured it out. Looking over the previous stuff in the thread, I suspect that the CHR ROM miight have a positive enable on it. why they didn't just invert /CE to it though I dunno. But it's a possibility. The disablement at the end of /RD would theoretically be to allow for the ALE event to latch the address from D to A0-7 and/or to read the nametables


Well my thought was they were using CHR /RD for the enable, but I'm leaning toward your theory that something is up with the access speed of the ROM. It's looking grim that I'll be able to read this via copynes so I yanked the ROM and read it directly (matches Gluk), also /CE must be normal, because I didn't have to jump it to VCC to read it. Only had to mess with A16 being non-standard.

I hate to throw in the towel before fully understanding what's going on, but the game is dumped now and I've spent enough time on this as it is. Besides that, the title and demo music are starting to wear on me :)

I do appreciate the help, and if have any last minute ideas before it goes back in the mail, I can test them out.

As for releasing the ROM, it's not my cart so Ill let the owner handle that as usual, but AFAIK it will be released.

About NTDEC, yeah, I think they were a pretty shady company from what I've seen. I wouldn't be too worried about them lobbing a copyright infringement suite at you. ;)

Profile will be in the DB shortly, need to scan some things first.