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

MastErAldo
Posts: 14
Joined: Wed Jun 29, 2022 6:07 am

Different behaviour between real NES and Emulators in Battle City

Post by MastErAldo »

Hello,
I made a reproduction cartrige to play a game from my childhood called Battle City (at that time I played it on a Famiclone which had the game bundled together with others). This time I want to play it on a real NES (PAL-A).

The problem is that the same rom burned on the eproms behaves differently between my NES and any emulator I tried (Mesen, Nestopia UE, FCEUX), in a way that is not glitchy, but most likely seems something like "if running on a Famicom do something, if on a NES do something else".
Let me explain:

The emulators I tried are forced to run as a PAL NES to make them as similar as possible to my real NES.

If I run the game on Mesen (or any other emulator) the main screen and the demo screen show the title "BATTLE CITY".
If I run the same exact rom on my NES the game behaves exactly the same, but the words "BATTLE CITY" don't show up in the main screen and in the demo screen. The same happens for the words "GAME OVER" that are also made by bricks, here's what i mean:
Image

The screens on the left are on the emulator, the ones on the right are reproduction of what I see on my NES/TV setup.
One thing I noticed is that the changes are not just on the graphics: on the demo screen the title can be destroyed shooting at it, so the bullets collide with it. On my NES the title is not just invisible, it really isn't there as the bullets cross the screen with no collision.

This is my current setup and how I set up my repro cart:

- I have PAL-A (Italy/UK/Australia) NES

- My NES has been modded by cutting the PIN 4 on the CIC chip on the NES and it happily accepts games from other regions.

- The game (Battle city) is this one: https://nescartdb.com/profile/view/3799/battle-city

- The rom in my possession (the one burned on the eproms) has the same CRC32 code as the one shown on nescarddb: 7E053E64 (PRG and CHR crc match too of course).

- The donor cartridge I used is the one from Soccer: https://nescartdb.com/profile/view/2498/soccer
The PCB is the NES-NROM-256-04. (I couldn't find on nescartdb a PAL Soccer on a NES-NROM-256-04 like mine, but it's identical to the one in the picture, except for the CIC chip which, in my case, is a PAL-B 3195A.
Image

- Battle city uses Horizontal mirroring, Soccer uses Vertical, so I unsoldered the glob on H and placed a new one on V on my cart (not doing so makes almost every graphics in the game invisible).

-The original Battle City PRG rom is 16kb and the CHR is 8kb. Soccer is 32/8, no mapper is used in neither.

-For both PRG and CHR i used two ST M27C512-10F1 eproms (100ns). The roms have been splitted and duplicated 4 times for the PRG and 8 times for the CHR using the program famiROM (which is also the one that shown the matching CRC32 checksum).

- The eproms have been soldered with no rewiring since on this PCB and with 28pin eproms no rewiring should be required since pinouts are compatible with the NES mask roms.

-The roms have been successfully burned and I'm sure of this because of it because after noticing the problem I unsoldered the eprom, read them again using my TL866II plus and the original file matches the one I dumped.

Now, my question is: what can cause this different behaviour and why I can't reproduce it on the most accurate emulators out there no matter what settings I use? (I may have missed some settings, but I already tried combinations of the most plausible ones)

Bonus question: if the answer boils down to a simple: "Yes the game can distinguish from famicom/nes using software tricks" I'm already happy, but since I haven't found an answer on the Internet, my second question would be: how?
I'm not an expert in NES development or the 6502 asm, but using the Mesen debugger I found the subroutine where the title is drawn and if I replace the JSR to that routine with a NOP the title actually doesn't show up, but I'm not skilled enough to understand if there's a "famicom or NES" check in place.

Many thanks in advance!
Attachments
pcb.jpg
bc.png
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 don't think there's any software problem that would cause this kind of thing to happen, it has to be a hardware failure of some kind.
Maybe double check that the chips read back successfully, and that reading and writing the PPU memory succeeds on that cartridge board.
Maybe try the NES Test Cartridge ROM first. It's also mapper 0 with horizontal mirroring (Vertical scrolling, V solder pad)

---

As for the unrelated question about games distinguishing what system they are running on, it's mainly different regions that can be distinguished. NTSC vs PAL vs Dendy can be distinguished by games performing measurements. You can tell the number of CPU cycles for a whole frame, the number of CPU cycles for a scanline, and the number of postrender scanlines that happen after the screen, but before the NMI interrupt. But NTSC Famicom vs NTSC NES is much harder to tell apart. I don't know if this actually works or not, but it might be possible to detect if the microphone bit is connected to something.

Battle City doesn't care what region it's running on, as it doesn't use any timed code.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
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 »

Thanks for the response.
What NES Test cart do you refer precisely? I found the "Nintendo - NTF2 Test Cartridge" and the Nintendo World Class Service - Control Deck Test Cartridge (USA).
Both seems to be NTSC only, If you refer to one of those, should I expect them to work properly in a PAL system?
I will socket the donor board and make some tries with these test roms or a more adequate one if you have suggestions.
Maybe double check that the chips read back successfully, and that reading and writing the PPU memory succeeds on that cartridge board.
The PRG rom i burned on the M27C512 has been desoldered and I read it again, it matches exactly the original PRG multiplied by 4.
As for the CHR I'll desolder and dump it too maybe tomorrow to double check, but I'm pretty sure will be the same of the original CHR for 2 reasons:
Image
As shown in the image, in order to make the "BATTLE CITY" title disappear, the tile in the char rom at address 0x10F0 should be empty, but since it is the same used by the wall protecting the eagle in the game, if I can't see the title I shouldn't see the wall too, but I see it.
I also though that maybe I left part of the CHR eprom empty and the game uses different aliased addresses for that same tile when showing as the title or as a game wall. Doing so on an 8k rom would refer to the same tile, but not on a 64k and that could probably explain why the title doesn't show, but the wall yes. However doing so in the demo I should see bullets hit invisible walls, while in my case bullets travel without a collision.
I also tried creating a rom with 16 kb PRG rom and a 64k CHR rom with 8k of the actual rom and the rest filled with 00 or FF, and set the iNES header accordingly, but with no differences.

So I expect the rom burned to match the original, but as said I'll test it to be 100% sure.
I Also never experienced any problem with my nes in any other game I played, but of course there has to be an explanation, I'm just puzzled by what can cause this issure since, as you said, Battle City doesn't use any trick to detect if famicom or nes.
As for the unrelated question about games distinguishing what system they are running on...
I thought that maybe Namco intended to name the game differently on EU/USA market, so the game would look for different tiles if a NES was detected instead of a famicom, but since the game never went outside Japan they never created those tiles, but that's just my supposition of course and the fact that I cannot reproduce the thing in an emulator kinda voids this theory.
Attachments
test.png
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

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

Post by Memblers »

I suspect Battle City may be doing something important with unitialized RAM. I had noticed something unusual while testing Battle City inside of Project Nested inside of Mesen-S. It would hang after a game over, but if I went into Mesen-S's options and forced it to clear SNES unitialized RAM, then it worked fine. Changing that option didn't seem to make a difference with any other games, so I attributed it to the game rather than the emulator.

This doesn't explain what you're seeing, but it at least there's one plausible reason differences might be seen between consoles.

edit: I'm pretty sure Mesen or some other emu has an option to trigger a breakpoint when unitialized RAM is read. So maybe that can be confirmed easily.
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 »

I desoldered the CHR rom and, as suspected, its identical to the original, so both the PRG and the CHR roms are identical.
I suspect Battle City may be doing something important with unitialized RAM
I checked using Mesen and Battle City does indeed 2 uninitialized RAM reads at the beginning (before showing the BATTLE CITY title)

One:

Code: Select all

  
  D4EF	LDX #$0F                 
  D4F1	LDA $0110,X              <-----THIS
  D4F4	CMP $C040,X              
  D4F7	BNE $D4FF                
  D4F9	DEX                      
  D4FA	BPL $D4F1                
  D4FC	LDA #$01                 
  D4FE	RTS                      
----------------         
  D4FF	LDA #$00                 
  D501	RTS                      
Two:

Code: Select all

D8F6	LDA $0B                  <------THIS
D8F8	CMP $0B                  
D8FA	BEQ $D8F8                
D8FC	RTS                      
I haven't checked it, but I assume that in the second piece of code an ISR is what at some point changes the value at $0B making it increment by one each time the routine is called.

However: Initializing the ram at 00, FF or with random values never reproduced the strange behaviour I'm experiencing with my NES.

Adjusting the cart position inside the NES or setting ram to random values only produced glitchy behaviours and therefore I'm inclined to think that the issue is not just a random bit flip in the cart, but rather my NES that behaves differently because the issue seems localized in a specific place and is very deterministic.

I'm going to socket the cart and program some eproms with roms that test my NES hardware if you can provide me the name of such roms, after all I'm now pretty confident that if there's an issue that is hardware related and not some specific code inside Battle City, some test must come up with something on the CPU, the PPU or the RAM.

The only thing that really puzzles me is: I've tried many different games (smb/duck hunt, wild gunman, zelda 1, zelda 2, a boy and his blob, metroid,rc pro-am, soccer, turbo racing) and never found issues or glitches, what are the odds that an hardware failure makes those games work well and this specific game work in a different way that doesn't affect in any way the gameplay, but just disables the titles??
Last edited by MastErAldo on Thu Jun 30, 2022 6:12 am, edited 1 time in total.
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 »

This might be totally unrelated, but there used to be a common problem in emulators where the Super Mario Bros title screen would be missing. Anyone remember why that was or if it could be related?
MastErAldo wrote: Thu Jun 30, 2022 6:10 am The only thing that really puzzles me is: I've tried many different games (smb/duck hunt, wild gunman, zelda 1, zelda 2, a boy and his blob, metroid,rc pro-am, soccer, turbo racing) and never found issues or glitches, what are the odds that an hardware failure makes those games work well and this specific game work in a different way that doesn't affect in any way the gameplay, but just disables the titles??
I agree, it seems unlikely that something wrong with the NES causes this 1 strange problem, yet no other games seem affected at all. Since only 1 cart does it, that would seem to generally point to something with the cartridge. Yet the cart is NROM so it is hard to imagine what could be wrong.
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 order to draw the "BATTLE CITY" bricks, it looks like the PRG code reads CHR tile definition bytes for the letters in "BATTLE CITY", builds up tile IDs for the corresponding brick quadrant tiles in RAM, then copies those tile IDs from RAM to the nametable.

In your repo cart, could there be something different happening when the PPU reads CHR ROM to update the screen (works correctly) versus when PRG code reads CHR ROM via PPU registers (works incorrectly)? I don't know much hardware-wise to know if that could be possible...
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 6:10 amI checked using Mesen and Battle City does indeed 2 uninitialized RAM reads at the beginning (before showing the BATTLE CITY title)

One:
[$0110 to $011F]
Note: In order to keep values like the high score after a reset, a game will check some uninitialized memory to see if it is an expected value that was stored from before the reset. In Battle City, it looks like the $0110 to $011F region is used for this check.
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 »

Ben Boldt wrote: Thu Jun 30, 2022 7:16 am This might be totally unrelated, but there used to be a common problem in emulators where the Super Mario Bros title screen would be missing. Anyone remember why that was or if it could be related?
I'm pretty sure that was because of ROM images that had been extracted from multicarts whose contents had been modified to remove copyright or add cheat codes (like enabling the World Select immediately after reset) - those hacks also tended to break the ability to press Select on the titlescreen to switch between 1-player and 2-player modes, requiring you to mash the button dozens of times before it would work.
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 »

Thanks to you all for the interestment.
Bavi_H wrote: Thu Jun 30, 2022 7:41 am In order to draw the "BATTLE CITY" bricks, it looks like the PRG code reads CHR tile definition bytes for the letters in "BATTLE CITY", builds up tile IDs for the corresponding brick quadrant tiles in RAM, then copies those tile IDs from RAM to the nametable.

In your repo cart, could there be something different happening when the PPU reads CHR ROM to update the screen (works correctly) versus when PRG code reads CHR ROM via PPU registers (works incorrectly)? I don't know much hardware-wise to know if that could be possible...
Unfortunately I'm also not an expert on the NES hardware (nor software btw), but the thing is:

- Excluding the the CIC chip on the cart (I disabled the one inside my NES, so I could also run the cart without it), on a NROM the connecttions go straight from the 72pins connector to the pins on the CHR and the PRG roms, any broken/shorted/misaligned connection on data or address lines would cause glitches or the game not running at all.

So of the 72 connectors we exclude
-4 cic lines
-2 GND
-1 5V
-16 Data lines (CPU and PPU)
-14 CPU address lines
-13 PPU addres lines
-10 expansion slot lines
-1 System clock

For a total of 61. Can any of the remaining ones be responsable for such problem?

- The PPU inside my NES can access the tiles it needs to draw the "Battle City" title and I say so because it actually draws the wall around the eagle which is made by the same tile used by part of the title.

- If, 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. On the other hand on my NES not only the title is not there, but also the collisions are gone, meaning that it's not just a graphic issue, there must be something in the code that executes differently.

Now from my understanding (please correct me if I'm wrong), the NES has a PRG bus that, among other things, connect the CPU with the PRG ROM and a CHR bus that links the PPU with the CHR rom and the only way that the CPU has in order to to read something from the CHR rom is to "ask" the PPU to read something from the CHR rom and present it inside a (I suppose) memory mapper register?

- IF what I just wrote is true then I made a test in Mesen that should exclude the PPU from the equation: I created a .nes file with the original PRG, but I filled the CHR with random bytes: I made the hypothesis that if for some reason the game levels are stored inside the CHR rom rather than the PRG (and read by the CPU via the PPU), having random bytes on the CHR rom would present different (glitched) levels and the collisions would be totally different from the normal ones. However, even with the garbled graphics I can see that the collisions are still there in the same way they are on an unmodified game.
Image

Moreover, since battle city has a level editor I can recreate (sort of) the BATTLE CITY title with brick walls in the same position, and that works as expected.
Attachments
randomchr.png
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 »

The 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
Battle City - Copy-0.png (4.63 KiB) Viewed 1449 times
(Also the "removing the CHR from the equation" screenshot you provided does "Have bricks" because there is junk, but the bricks are not in the same pattern as the game font. I know, it's hard to tell then when the font data is all random garbage, and the brick graphics are random garbage.)

So there might be a connection flaw that's preventing the cartridge from reading CHR-ROM via the CPU.
The PPU Address of the "B" character is 0x12A0. If that were being treated as a VRAM read instead of a CHR-ROM read, it would have read from one of 0x22A0, 0x26A0, 0x2AA0, or 0x2EA0.

The game clears all the PPU's RAM (nametables) before it reads the font at both the Title Screen and the Demo, so if CHR reads were somehow giving you RAM data instead of CHR-ROM, that could cause 00 bytes to be read back.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
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 »

The PPU is the interface for reading and writing on the PPU bus, so there's no way for anything connected to the PPU bus to know whether the PPU is reading on behalf of the CPU, or reading as part of normal screen rendering. If the cartridge blocks CHR-ROM reads, then the PPU would be unable to display pixels on the screen, so the read must be going through without issue.

It can't be a bus conflict (i.e., PRG-ROM inappropriately enabled when CPU is trying to access memory outside of 8000-FFFF), because that would interfere with RAM reads and register reads (like reading joypads), and because the game clearly works, and this is an actual NES NROM board, I wouldn't expect this to be a problem.

I'm hesitant to say it's a faulty NES/FC because there may be something about cart hardware I'm overlooking or just don't know about, or maybe some kind of PPU revision difference?
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 »

Does the PPU latch the CHR data bus the same way no matter what kind of read it's performing? Some weird timing quirk combined with a questionable ROM might explain why the PPU is only able to read the ROM for rendering.

Got any other (E)EPROMs you could try?
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 »

Is the ROM chip bigger than the original, and if so, did you repeat the data to fill the whole chip?
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 »

(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.
Joe wrote: Thu Jun 30, 2022 11:43 am Does the PPU latch the CHR data bus the same way no matter what kind of read it's performing? Some weird timing quirk combined with a questionable ROM might explain why the PPU is only able to read the ROM for rendering.
I'm afraid that's not the case because the missing title in the demo level is not just "not rendered tiles", but the walls (intended as actual obstacles in the game) are missing, so I would belive that in that case the bricks are not rendered because the walls in the game are not there, otherwise I should have just invisible walls, but the bullets would hit them.
Do you mean other games or other eproms to burn?
I can try burning eproms from a different manufacturer (these ones are from ST).
I have plenty of them and everyone is UV erasable, so trying different roms is not a problem.

If 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.
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.

Anyway attached are the photos of my NROM in the case they trigger some ideas, but to my (unexpertised eye) it looks like a normal NROM.
Attachments
front.jpg
back.jpg
Post Reply