Battletoads Double Dragon Powerpak Freeze

[icon0319]

I have searched the entire forum and google and everyone I see state that the game is working which it looks like it does until you reach the Abobo fight. As soon as Abobo punches through and the fight is about to start the game freezes on my Powerpak. I have tried No-Intro and GoodNES versions of the Rom with no luck.

I am using the following configuration:

1.35b2 Mappers
Loopy's Mappers as of 03-02-2015
Power Mappers V2.3

Anybody else experience this?

[thefox]

Never had this problem. I have played through that part many times.

Additionally, it's very unlikely to be a mapper problem, because AxROM is a super simple mapper.

[koitsu]

Provide ROM filename and checksum (MD5 and/or SHA1). Please don't upload the ROM, and please don't just provide the filename.

[icon0319]

Filename: Battletoads & Double Dragon - The Ultimate Team (U)

Checksum: CEB65B06

[icon0319]

Standby that was CRC32

[koitsu]

CRC32 I can work with, though SHA1 would be extra precise. NestopiaUE has a NstDatabase.xml entry for (potentially) this game (if the SHA1 matches):

Code: Select all

    <game>
        <cartridge system="NES-NTSC" dump="ok" crc="CEB65B06" sha1="A14563325B0F33C358142E7363D31614722FDDB1">
            <board type="NES-AOROM" mapper="7">
                <prg size="256k" />
                <vram size="8k" />
            </board>
        </cartridge>
    </game>

But it looks like it's just to force the dump="ok" flag for older GoodNES databases which don't have this ROM marked as good/verified (the one I have is marked such).

I can't reproduce the problem unless you give specifics of "the Adobo fight" and how to reach it/get to it. Warning: I REALLY hate Battletoads games in general. Bordering on loathe. So if it's some battle half way through the game or near the end, yeah, I'm not going to sit through that (yes, that is how much I hate Battletoads games). So, if there's a Game Genie or PAR code that might let me skip to that part of the game for testing, I can make a patched ROM with that applied and try it on my NES + PowerPak (for confirmation) and then try to examine what's going on maybe in a debugger to see if there's something abnormal. Another option would be if the game has a level select cheat. I do not own the cartridge, so I can't compare there.

thefox is right -- AOROM is incredibly simple/common, so this sounds like something that might actually be a real game bug. Another possibility could be bus conflict oddities, but I'd rather not speculate.

P.S. -- Why is it always these horribly annoying Rare games that bring people out of the woodwork? It's like being stung by a thousand bees. LOL

[tepples]

I can't reproduce the problem unless you give specifics of "the Adobo fight" and how to reach it/get to it.

My first stop would be GameFAQs. Abobo is the boss of world 1.

Another option would be if the game has a level select cheat.

Again GameFAQs. One warp and lives code, entered at character select, is B, A, Down, B, Up, Down. Another is Down, Up, Up, Down, A, B, B, A.

P.S. -- Why is it always these horribly annoying Rare games that bring people out of the woodwork?

Possibly because annoying Rare games are good at bringing out timing and bus problems in NES emulators and flash carts.

It's like being stung by a thousand bees. LOL

Also Rare, and also annoying

[koitsu]

Thanks tepples. Getting 10 lives with the code + warping to 1-2 suffices. Pretty easy to beat the few hands right before Adobo. The below is on a front-loading NES (NTSC), no mods, just the cheat code.

Test 1: Adobo punched through the wall and began to approach, disappeared (!), and then I automatically beat the level.

Power-cycled NES, went through usual menu, picked ROM, loaded game, cheat code, etc...

Test 2: Adobo punched through the wall and began to approach, screen shifted abruptly (wrong PPU scroll register offsets or unexpected PPU write values) + some graphical corruption, game crashed (noise channel stuck on, so CPU is still actively running in a loop doing something)

I can make a video + upload to YouTube if folks would like to see the behaviour in question.

So, I have a gut feeling this is essentially a quirk/bug with the game being used on a PowerPak. It is not necessarily a game bug, nor is it a PowerPak bug. Several games are like this. (That said, it COULD actually be a real bug in the game that isn't immediately evident with a real cart, but it could also be by design).

Expanding: odds are there's a part of ZP/RAM that has a different value in it on actual hardware (cart) compared to the PowerPak. The PowerPak, like the EverDrive and similar devices, to function ends up using parts of ZP/RAM on the NES (for the menuing system and several other things) that an actual cartridge wouldn't use. There is no "standard" for this on the NES (i.e. the hardware itself does not "initialise" memory a certain way -- it varies slightly based on power-off vs. reset, how long it was powered off for, etc.). This is all covered in the first bullet items here:

PowerPak: https://wiki.nesdev.com/w/index.php/Pow ... imitations
EverDrive N8: https://wiki.nesdev.com/w/index.php/Everdrive_N8 -- see bottom of page
NES itself: https://wiki.nesdev.com/w/index.php/CPU_power_up_state -- see "Internal memory" explanation

This same problem affects emulators, though it may vary per emulator because different ones (and different versions of those emulators) pre-initialise RAM to different values -- they cannot "simulate" a NES in this regard. So this puts more focus on it being a "quirk/bug" in the actual game that use of a PowerPak or EverDrive or possibly an emulator triggers.

Confirming this requires someone to actually reverse-engineer the game and figure out what ZP/RAM locations the game uses for Adobo busting out of the wall + what is used right as he begins to approach you. Rare games are notorious for being extremely well-written (i.e. highly optimised and complex), which makes this task likely even more difficult.

If someone wants to RE this game and figure it out, that'd be awesome, but then a patched ROM would be required. Use of a Game Genie code may be an alternate workaround/solution.

I'm trying to think of a way to debug this using the pre-selectable RAM value features of things like FCEUX SVN (rainwarrior recently added this, I think) or Mesen, but the problem is that you'd need to compare "bad/broken" ZP/RAM contents (e.g. after a crash) to that of "working" ZP/RAM contents **at that exact moment of the crash** (since a working game likely tinkers with tons of ZP/RAM variables).

I'll see if I can reproduce it in an emulator that lets me change the ZP/RAM pre-init at least.

[Myask]

Rare games are notorious for being extremely well-written (i.e. highly optimised and complex), which makes this task likely even more difficult.

Good thing you clarified well-written. BT&DD in particular does not handle violated assumptions well, and didn't cover all those assumptions. (AGDQ 2013 glitch exhibition)

[rainwarrior]

On my NES + PowerPak (with a ROM whose PRG matches that CRC) I don't seem to have any problem with Abobo.

Currently using latest PowerMappers AxROM but I'm certain I've played past Abobo several times in the past with the "official 1.34" AxROM mapper.

[icon0319]

Koitsu,

i just want to say thank you for diving deep into this. The results of your Test 2 is exactly what I experience every time I play.

Rainwarrior,

Can you PM me where you procured your ROM from? The checksums being the same I would think they are the same file but just in case i just want to eliminate ROM as the root cause here.

[thefox]

Well, I checked it out in NDX.

Uninitialized RAM doesn't seem to be the cause. The game initializes all RAM except $FD and $FE right away. $FE is initialized to #$28 before title screen. I couldn't trigger further access to those memory locations before the Abobo fight.

However, right after Abobo punched through the wall, game accesses some values at $600X (the exact value seems to depend on something, didn't look into it, I saw $6001..$6003, then $6009..$600B). Code is at $D762. It's an indirect access via LDA (addr),y, so it's probably a bug. Later on I saw the same code being used to access some data from ROM.

Since this game uses AxROM, it obviously cannot have any memory at $6000..7FFF, so it will end up using whatever value happens to left in WRAM when used on PowerPak (if the corresponding mapper implements WRAM for AxROM), or something else (if the mapper doesn't implement WRAM). In NDX/Nintendulator it's implemented as open bus so it ends up receiving $60.

One quick fix you can try is to load a .SAV file full of zeros (or $FF, or something else) before you start the game.

[rainwarrior]

I was wondering earlier re: the idea of differing RAM setup, whether this is basically dependent on the file layout of your CF card or something?

I have a mostly complete collection of licensed NES titles, organized in folders by letter, e.g. paths like "ROMS/B/Battletoads (U).NES"

So... this particular ROM will be opened from a folder with about 75 files in it, I think. Might that be a difference that sets the game up to fail or not?

Can you PM me where you procured your ROM from? The checksums being the same I would think they are the same file but just in case i just want to eliminate ROM as the root cause here.

I got it from some torrent a very long time ago, but I'm pretty certain we have the same ROM. A CRC32 hash collision is unlikely, though remotely possible, but if you're worried about that check the SHA1 (Nestopia UE will show it under View > Image Info...) as well, which should be: A14563325B0F33C358142E7363D31614722FDDB1

(I would have rather extreme doubts about an SHA1 and CRC32 hash collision happening at the same time.)

[icon0319]

Rainwarrior,

I can confirm we have the same file. As for layout I am structured the same exact way. It's just strange how we have the same configuration (Mappers, Roms, etc) and you don't have the issue. I have never read anywhere that there was differences in hardware for Powerpak since i was an early adopter and have had mine since 2007-2008ish

Thefox,

Thank you for taking your time to help me look into this. I tried an empty SAV file and it works to patch the issue. I have it renamed to the ROM file so it automatically loads when I open the ROM so this is an easy fix. I'm glad I no longer have to use my cartridge to play the game and can just leave my Powerpak in my NES.

[koitsu]

The ROM I used is the same as rainwarrior:

Code: Select all

Filename: Battletoads & Double Dragon - The Ultimate Team (U) [!].nes
CRC32:    CEB65B06
MD5:      35933222cf8658f7c6679fc7de630aaa
SHA1:     A14563325B0F33C358142E7363D31614722FDDB1

I think thefox's explanation is spot on. I assumed RAM pre-init issues because it's the more common problem. Expanding: Battletoads & Double Dragon - The Ultimate Team (NTSC/USA) uses mapper 7 / AOROM board, which is is often subject to bus conflicts. Whether or not pin 31 (CE) on that particular game is held high is unknown, but possibly it is. There are no PCB pictures for the NTSC/USA release in BootGod's DB. Maybe I should try to find a cartridge and supply such photos -- edit: oh, never mind, this is one of those games that's being sold for hundreds of USD because people are assholes (and those which are lower-priced are under constant bidding wars -- nobody on eBay is selling them with "Buy It Now!" because they know they'll get more from bidding wars). That is why there aren't PCB photos: nobody's gonna shell out hundreds of bucks for this one game.

I'm really not sure how you deal with this with emulation or on an FPGA (like the PowerPak) other than having a cartridge database that provides that info. The NES 2.0 header/file format even mentions this problem with mapper 7, prompting the need for "submappers" (and there are test ROMs provided for exactly that, written by -- you guessed it -- rainwarrior). :-)

Supposedly thefox's PowerPak PowerMappers v23 releases (and/or later) provide NES 2.0 header support, so basically a modified version of the ROM that sets up the NES 2.0 headers properly for this + use of PowerMappers v23 or later is probably the "cleanest" way to solve it.