Different behaviour between real NES and Emulators in Battle City

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: Different behaviour between real NES and Emulators in Battle City

Post by Joe »

MastErAldo wrote: Thu Jun 30, 2022 12:35 pm
(Also the "removing the CHR from the equation" screenshot you provided does "Have bricks" because there is junk...
I know, but my point was: The layout of the levels describes tile-by-tile what kind of obstacle is present (brick wall, steel wall, water...). If the layout of the levels is stored (for some reason) in the CHR rom and is read by the CPU through the PPU, then replacing the CHR rom with garbage would give me unplayable levels, but instead the levels are perfectly playable, just with garbage tiles, but the gameplay is not affected, and that's why I belive that the CHR rom and possibly the PPU are not the culprit, because in my case the demo level IS different, since the walls composed by the title "BATTLE CITY" are not only invisible, they really aren't there. I can double check this maybe tomorrow by connecting only the PRG rom: I expect to see a screen similar to the one I posted on Mesen, but without the garbage tiles that compose the title in the demo level.
Most of the levels are stored in PRG ROM. Only the brick walls shaped like letters are stored in CHR ROM.
MastErAldo wrote: Thu Jun 30, 2022 12:35 pmIf you mean games, then also yes, but do you have suggestions? As said I already tried different NROM games and they work, but maybe we can definitively exclude a problem inside my NES (or confirm it) if you can name me a good test rom that possibily checks cpu, ram and ppu of my NES.
Which games did you try? Super Mario Bros. stores the title screen layout in CHR ROM, so if the title screen displays correctly then the problem is with the EPROM you're using for Battle City.
Bavi_H
Posts: 193
Joined: Sun Mar 03, 2013 1:52 am
Location: Texas, USA
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by Bavi_H »

MastErAldo wrote: Thu Jun 30, 2022 9:59 amIf, using the tile editor in Mesen, I clear the brick tiles, the title is now inbisible, but in the demo screen collisions between bullets/tanks still happen against this now "invisible" Battle City title.
Look at what happens if you use the tile editor in Mesen to clear the tiles for the letters A B C E I L T Y. When you do this, the BATTLE CITY letter bricks are missing and the collisions no longer happen. However, in this test, the letters are also blanked out in normal text.

In your repo cart, the letter tiles are working correctly in normal text. So I was wondering if there could be some problem that only happens when the game looks at the letter tiles to decide which brick tiles it needs to use for the letter-shaped bricks. When the PPU looks at the letter tiles to put normal text on the screen it works fine.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by Quietust »

MastErAldo wrote: Thu Jun 30, 2022 12:35 pm
s the ROM chip bigger than the original, and if so, did you repeat the data to fill the whole chip?
Yes, I used 2 ST 27c512 (64kb) and so the PRG is repeated 4 times and the chr 8 times. The rom is pin compatible since is 28pins and I already used in an NROM (actualy another soccer game with the same exact pcb) for Wild Gunman.
How are the upper address lines of those ROMs connected? Normally, if you're going to plug a 64KB ROM into an 8KB socket then you'd want to connect A15+A14+A13 to either +5V or GND, not some signal that could be allowed to vary (or, worse yet, allowing any of them to float).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Bavi_H
Posts: 193
Joined: Sun Mar 03, 2013 1:52 am
Location: Texas, USA
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by Bavi_H »

In your first post, it looks like you modified an emulator screenshot to show what the screen looked like with your repo cart. If you can take an actual photo of the screen, we might notice some pattern in the image that indicates some kind of fault between signal lines.

For example, It looks like the game only uses the lower plane of each letter tile (CHR ROM addresses ending in a hex digit of 0 to 7) when deciding which brick tiles to use for the letter-shaped bricks. If there is a fault somewhere that causes each data bit from the CHR ROM to get ANDed with PPU A3, then the lower plane of each tile would appear as all zeros. To simulate this, I used Mesen's Memory Viewer to zero out CHR ROM addresses ending in a hex digit of 0 to 7*. This causes the BATTLE CITY bricks to be missing and no collision to happen. However, this also changes the colors and reduces the graphic details. When you used your repo cart, did you happen to notice any colors like the following?:

battle-city-test.png
battle-city-test.png (2.18 KiB) Viewed 1101 times

____

* Example method to zero out CHR ROM addresses ending in a hex digit of 0 to 7:
1. In Mesen's Memory Viewer, make sure the Number of Columns is 16.
2. In the View drop-down box, choose CHR ROM.
3. Select the entire CHR ROM, copy it, then paste it into Notepad++.
4. In Notepad++, use Alt key selection methods to remove the left half of every line and replace it with zeros.
5. Copy all the text in Notepad++ and paste it back into Mesen's Memory Viewer.
MastErAldo
Posts: 14
Joined: Wed Jun 29, 2022 6:07 am

Re: Different behaviour between real NES and Emulators in Battle City

Post by MastErAldo »

Joe wrote: Thu Jun 30, 2022 1:40 pm Which games did you try? Super Mario Bros. stores the title screen layout in CHR ROM, so if the title screen displays correctly then the problem is with the EPROM you're using for Battle City.
The only cart with SMB is the one boundled together with duck hunt. It uses a mapper thugh, not sure if it makes any difference, but both games play fine with no issues.
Look at what happens if you use the tile editor in Mesen to clear the tiles for the letters A B C E I L T Y. When you do this, the BATTLE CITY letter bricks are missing and the collisions no longer happen. However, in this test, the letters are also blanked out in normal text.

In your repo cart, the letter tiles are working correctly in normal text. So I was wondering if there could be some problem that only happens when the game looks at the letter tiles to decide which brick tiles it needs to use for the letter-shaped bricks. When the PPU looks at the letter tiles to put normal text on the screen it works fine.
Ah I see now yes, clearing the tiles used as font does indeed clear the title AND the collisions! But, as you said, it also clears the characters used for normal text, but it seems we are getting closer to something.
It indeed seems that the PPU cannot read the tile fonts when it needs them to display the "brick style" letters, be the title or the "GAME OVER".
I created a nes file with a 64kb CHR and only the first 8kb containing the actual rom (the other bytes are 0) thinking that maybe for the title the PPU uses a different address, but the game works just fine. If the problem is likely not inside my NES do you have any clue on what can make the PPU not read those tiles?
Quietust wrote: Thu Jun 30, 2022 3:02 pm How are the upper address lines of those ROMs connected? Normally, if you're going to plug a 64KB ROM into an 8KB socket then you'd want to connect A15+A14+A13 to either +5V or GND, not some signal that could be allowed to vary (or, worse yet, allowing any of them to float).
No modifications have been done on the PCB. Plugging a M27c512 in the CHR socket would connect:

eprom PIN 1 (A15) to 5V
eprom PIN 28 (A14) to 5V
eprom PIN 27 (A13) actually I just found that is left floating (I actuallty though it was connected to A14-5V, bu there's no continuty)

On the PRG rom A15 is 5V and address A14 is connected to pin 41 in the 72 cart connector.

I will definitively connect the eprom PIN 27 to 5V just like A14, but since the eprom is repeated 8 times (already verified it) can it be really the problem? What I mean is that even if A13 floats between 0 and 1 the byte read would be the same, just from a different memory cell. Worth give it a try anyway.

I also have a 2764 which is exactly 8kb, but I tend to keep those for atari 2600 games since they are not CMOS and slower, might give them a try too.
In your first post, it looks like you modified an emulator screenshot to show what the screen looked like with your repo cart...
...However, this also changes the colors and reduces the graphic details. When you used your repo cart, did you happen to notice any colors like the following?:
Yes I edited a Mesen screen because at that time I had already desoldered the PRG rom and was not sure to put it back, but in the light of the latest posts it might be a good idea to solder again the prg and the chr so I can take some photos.
The graphics however appeared normally when played on the NES, not like the image you posted.

Tomorrow I'll put the cart together and make some photos,
Thanks!
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: Different behaviour between real NES and Emulators in Battle City

Post by Ben Boldt »

Joe wrote: Thu Jun 30, 2022 1:40 pm Most of the levels are stored in PRG ROM. Only the brick walls shaped like letters are stored in CHR ROM.

Which games did you try? Super Mario Bros. stores the title screen layout in CHR ROM, so if the title screen displays correctly then the problem is with the EPROM you're using for Battle City.
It sounds like it has trouble accessing the layout data from CHR-ROM, for some reason specific to this particular cart. How is the data laid out in CHR-ROM? Say that large letter layout stuff is stored in the 2nd half of ROM and everything else used at the beginning of the game is in the first half. That could point to an incorrect CHR-ROM address bit, for example PPU A12.

When you verified the data, did you connect the EPROM directly to a ROM dumper, or did you use a cartridge dumping tool?

Please provide photos of the PCB with your EPROMs inserted; maybe we find an incorrect connection.
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: Different behaviour between real NES and Emulators in Battle City

Post by aquasnake »

I guess the pirate ROM of battle city depends on the access to the specific address of stack or zero page. Multicarts or emulators will clear iRAM in advance, and uninitialized random value of iRAM may cause problems
MastErAldo
Posts: 14
Joined: Wed Jun 29, 2022 6:07 am

Re: Different behaviour between real NES and Emulators in Battle City

Post by MastErAldo »

When you verified the data, did you connect the EPROM directly to a ROM dumper, or did you use a cartridge dumping tool?

Please provide photos of the PCB with your EPROMs inserted; maybe we find an incorrect connection.
I desoldered both eproms from the cart (PRG and CHR) put in my TL866II+ and dumped. Both checked ok with no differences with the original rom, since both eproms are 64k the PRG is multiplied by 4 and the CHR by 8.

Here is the PCB with the new eproms:
Image
Image
I also changed the eproms from the original ones: the CHR rom is still a M27c512 developed by ST since being a 100ns is the fastest I have.
The PRG rom is a Texas Instruments TMS27C512.

I also connected address 13 to 5V since it was left floating, but unfortunately got no difference in the result.

Here are 2 photos of the actual game on my setup. Apologize for the quality but taking pictures to a CRT is harder than I expected. Anyway the colors look the same as in Mesen.
Image
Image
I guess the pirate ROM of battle city depends on the access to the specific address of stack or zero page.
The rom I burned in the eproms is not a hack/pirate rom, is the original one with
PRG checksum: 912D82C5
CHR checksum: 6E32D231
Combined: 7E053E64
Attachments
main-notitle.jpg
game-notitle.jpg
front-eproms.jpg
back-eproms.jpg
User avatar
rainwarrior
Posts: 8732
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by rainwarrior »

Dwedit wrote: Thu Jun 30, 2022 10:26 amThe game is indeed reading its own font from the CHR ROM to plot the bricks. Just copy-pasted the C over the B and got this:

Battle City - Copy-0.png
That really neat! What a way to try and save PRG space.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by Dwedit »

I see an obvious solder bridge connecting two pins on the back there?
(For those somehow unable to see it, it's the right hand chip, lower left area)

The SMB1 cartridge doesn't have any bridges in that area:
Image

(I assume it's okay to hotlink nescartdb.com from here, as both nesdev.org and nescartdb.com are owned by Brizzo)
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: Different behaviour between real NES and Emulators in Battle City

Post by Joe »

MastErAldo wrote: Thu Jun 30, 2022 4:43 pmThe only cart with SMB is the one boundled together with duck hunt. It uses a mapper thugh, not sure if it makes any difference, but both games play fine with no issues.
The one with Duck Hunt should be fine. So, you're saying the title screen appears normal when you select SMB? If so, that means your NES is fine and the problem is your repro cartridge.
MastErAldo wrote: Fri Jul 01, 2022 6:27 amthe CHR rom is still a M27c512 developed by ST since being a 100ns is the fastest I have.
Have you tried a different manufacturer? Your TMS27C512-1JL seems to be 170ns, which should still be fast enough for a CHR ROM.

Where did you get those ST EPROMs? If you bought them online, they may be damaged, counterfeit, or factory rejects.
Dwedit wrote: Fri Jul 01, 2022 12:58 pmI see an obvious solder bridge connecting two pins on the back there?
That's CHR A13. It's supposed to be like that.
Last edited by Joe on Fri Jul 01, 2022 1:31 pm, edited 1 time in total.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by Quietust »

Dwedit wrote: Fri Jul 01, 2022 12:58 pm I see an obvious solder bridge connecting two pins on the back there?
(For those somehow unable to see it, it's the right hand chip, lower left area)

The SMB1 cartridge doesn't have any bridges in that area:
Image

(I assume it's okay to hotlink nescartdb.com from here, as both nesdev.org and nescartdb.com are owned by Brizzo)
That bridge was added in order to ensure that all "extra" address lines had a known consistent state - without it, A13 was left floating and could've potentially resulted in glitches.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
MastErAldo
Posts: 14
Joined: Wed Jun 29, 2022 6:07 am

Re: Different behaviour between real NES and Emulators in Battle City

Post by MastErAldo »

The one with Duck Hunt should be fine. So, you're saying the title screen appears normal when you select SMB? If so, that means your NES is fine and the problem is your repro cartridge.
Well I'll be damned! It WAS working at least last time I tried it which was less than a month ago and now I get the exact problem also on SMB. How naive not having checked it in the first place...

At least now we know what is the real problem... my NES.
Tomorrow I'll open it to check if there is something clearly wrong, but at this point, if the fault is inside the PPU and not just loose connections/oxydized contacts in the NES cart header, I guess the only solution is to pick a new nes motherboard.

Thank you all so much for helping me solve this problem!
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Different behaviour between real NES and Emulators in Battle City

Post by Drag »

I'm glad this was straightened out, because I absolutely could not find anything on the cartridge-side that jumped out at me as something that would cause that kind of a fault (but again, I'm not as familiar with electrical engineering to know for sure. Meaning, if it were bus capacitance or access times on the EPROM or other timing issues, I wouldn't have been able to figure it out).

If the PPU can read from CHR-ROM successfully enough to display coherent graphics, then the $2007 read (a.k.a., the thing where the program is able to read bytes from CHR-ROM through the PPU) should work too since it works the same way. So, if graphics work fine, but $2007 reads don't, then the read buffer is probably broken, meaning the PPU has a fault. I was just too uncertain about it. :P
Post Reply