Battletoads Double Dragon Powerpak Freeze

[icon0319]

koitsu,

I own the game. I could take photos for you. Other than top and bottom photos of the PCB is there any areas you would want to have a closer look at or do you want to determine that after I take the pictures?

[rainwarrior]

The submappers and my mapper 7 tests are for bus conflicts with ROM. There's no test for the WRAM region, as that's not really a submapper issue. No AxROM boards had WRAM.

For accurate emulation WRAM should simply not be present there, and it should have open bus behaviour. (A NES 2.0 header could be used to specify that WRAM is added there, though, if there were some future homebrew that needed it.)

[thefox]

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.

The NES 2.0 support in PowerMappers is quite limited (the main use case was to configure the CHR RAM size).

BTW, it's not a bus conflict issue. It's a matter of the game reading $6000..7FFF despite not having WRAM (exactly same issue as in Low G Man). PowerMappers, IIRC, will map WRAM to $6000..7FFF regardless of the mapper, so that's why loading an empty .SAV file fixes it. It may have worked on the official RetroUSB mappers if they don't map the WRAM at all in AxROM, although the open bus behavior on PowerPak still would not match the original cart, so it working would have been a lucky coincidence.

This gives me another reason to initialize WRAM to a known state when loading games that don't have the "battery backed SRAM" bit set in the iNES header. (Another option would be to disable WRAM for NROM/AxROM and other mappers which are not "supposed to" have it, but I kind of like having the WRAM there for homebrew development.)

[koitsu]

I own the game. I could take photos for you. Other than top and bottom photos of the PCB is there any areas you would want to have a closer look at or do you want to determine that after I take the pictures?

If you're going to take PCB photos, I recommend you skim BootGodDB to get an idea of how clear (and high resolution) the photos need to be. All the other information about the cartridge has to be provided too (here's a good example).

[koitsu]

Thanks guys, sorry I got it wrong.

This gives me another reason to initialize WRAM to a known state when loading games that don't have the "battery backed SRAM" bit set in the iNES header.

This sounds like the easiest approach.

[rainwarrior]

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.

Tried this, loading battery RAM with $FF before starting the game gives me the crash at Abobo. Loading $00 it seems to play fine.

SAV files are attached for convenience.

If you rename the 00 one to have the same name as your ROM you should be able to get it to auto-load whenever you want to play it. (Does it need to have the battery bit flipped in the header too for auto-load?)

[thefox]

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.

Tried this, loading battery RAM with $FF before starting the game gives me the crash at Abobo. Loading $00 it seems to play fine.

Too bad it's the exact opposite in Low G Man. I wonder if WRAM filled with the hibyte of address ($60, ..., $61, ..., $62, ..., $7F) would work in both?

This makes me wonder how many other games inadvertently depend on values returned from $6000..7FFF.

[rainwarrior]

Hm Low G Man's reads seem to be in a range around ~$7C80, though the value is then given a CMP #$30, so I guess it's tolerant to a wide range of "high" values.

I didn't realize the open bus behaviour should return the high address byte. My patch should have done things differently, though I guess it's only a moot point.

[thefox]

Hm Low G Man's reads seem to be in a range around ~$7C80, though the value is then given a CMP #$30, so I guess it's tolerant to a wide range of "high" values.

I didn't realize the open bus behaviour should return the high address byte. My patch should have done things differently, though I guess it's only a moot point.

The value will be (under typical conditions) whatever value was on the data bus before the open bus access. So in the case of LDA (addr),y the last access before the open bus access is the one where it reads the hibyte of the address from zeropage. Same happens for e.g. LDA $6000 (fetch opcode, fetch $00, fetch $60, fetch from $6000).

(For indexed addressing modes like LDA addr,y filling WRAM with this pattern does not perfectly simulate open bus, because one could do LDA $60FF,y with Y=1. With proper open bus this should return $60, but with this simulation it returns $61.)

I tested BT&DD with WRAM filled with $60..$7F, and it works. I attached the file.

[rainwarrior]

Ah, so that "high byte of the effective address" version is an approximation that is potentially off by one, if Y causes a page crossing?

(I guess if Y is evenly distributed, maybe the first 1/4 of each page should be -1 for a better approximation? Probably in real examples Y is usually low, though.)

[tepples]

The one where thefox learns occupatio

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

What do you call a Mega Man boss whose power is to emit a triangle wave at 49 Hz? The same thing you call a game with a bug that causes it to depend on WRAM being nonexistent: Low G Man.

It's a matter of the game reading $6000..7FFF despite not having WRAM (exactly same issue as in Low G Man).

Oh wait, I'm slowpoke.

(Another option would be to disable WRAM for NROM/AxROM and other mappers which are not "supposed to" have it, but I kind of like having the WRAM there for homebrew development.)

Then split the difference: disable it entirely for iNES, and enable it in NES 2.0 if and only if the WRAM size field of NES 2.0 is nonzero.

I wonder if WRAM filled with the hibyte of address ($60, ..., $61, ..., $62, ..., $7F) would work in both?

I just wrote a Python program to generate such a WRAM file:

Code: Select all

#!/usr/bin/env python3
"""
This program makes an 8192-byte file containing 256 bytes of value
$60, 256 bytes of value $61, through $7F.  It's useful to simulate
open bus in NES games that lack WRAM on the cartridge but
inadvertently read the area conventionally decoded to WRAM anyway,
so long as the game doesn't try to *write* to WRAM.

By Damian Yerrick
License: WTFPL
"""
with open("openbus.sav", "wb") as outfp:
    for value in range(0x60, 0x80):
        outfp.write(bytes([value]) * 256)

I'll attach its output.

I tested BT&DD with WRAM filled with $60..$7F, and it works. I attached the file.

Oh wait, I'm slowpoke again.

Ah, so that "high byte of the effective address" version is an approximation that is potentially off by one, if Y causes a page crossing?

Yes, and the controller test that I've worked on recently relies on similar behavior to distinguish an NES from a Famicom.

[Great Hierophant]

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.

There is a photo of the front of the PCB, NTSC version :
http://bootgod.dyndns.org:7777/profile.php?id=2847

Also the PAL version :
http://bootgod.dyndns.org:7777/profile.php?id=4531

Hm Low G Man's reads seem to be in a range around ~$7C80, though the value is then given a CMP #$30, so I guess it's tolerant to a wide range of "high" values.

I didn't realize the open bus behaviour should return the high address byte. My patch should have done things differently, though I guess it's only a moot point.

If you would like to make a patch for BT&DD, I doubt anyone would complain.

[Great Hierophant]

For what its worth, I was able to get to level 3-2 with my NES PowerPak and a correct NTSC ROM without using a sav file. I was also using :
1.35b2 Mappers
Loopy's Mappers as of 03-02-2015
Power Mappers V2.3

[thefox]

For what its worth, I was able to get to level 3-2 with my NES PowerPak and a correct NTSC ROM without using a sav file. I was also using :
1.35b2 Mappers
Loopy's Mappers as of 03-02-2015
Power Mappers V2.3

It depends on what happened to be in your WRAM when the game started.

[thefox]

Another game that seems to suffer from uninitialized WRAM accesses is Ultima: Exodus.

Initializing the WRAM to certain states before the game starts causes various artifacts like shaking text, corruption of the font's CHR-RAM uploads, and audio garbage. This is quite obvious in NDX when memory randomization is turned on, however the battery bit must be disabled in the iNES header to see the effect, because otherwise the WRAM will be loaded from a file and not randomized. On PowerPak the WRAM (save RAM) has to be explicitly loaded so this problem is present.

Why didn't it affect the original cart, then? The problem seems to clear itself up always after a reset (after the game has initialized parts of the WRAM), and therefore stays valid for further power-ons because of the battery-backed memory.

So, seems like the only good way to fix this issue in PowerPak mappers is to initialize the WRAM always (even if game uses battery backing), except when a .SAV file has been loaded before starting the game.

(Thanks to koitsu for reporting the issue.)