Some implementations of mapper 34 conflate NINA-001 and BNROM; this should only matter if your code writes to $7FFD,E,F and needs a bankswitch to not occur.
Some implementations don't enforce bus conflicts.
BNROM is so simple that I'd be inclined to suspect uncharted 2A07/2C07 territory instead.
Other differences to look into include initial RAM contents and initial bank number. Recent versions of FCEUX allow for different RAM preloads ($00, $FF, and random).
and all the banks contain the same reset code, which switches to bank 0 after the first vBlank.
the problem i'm having is thatSlight timing differences between NTSC chipset (2A03/2C02) and the PAL chipset (2A07/2C07) can affect mapper compatibility in edge cases. This includes not only the number of dots per CPU cycle (3 vs. 3.2) but also what fraction of time the M2 is high vs. low, when /PRGSEL goes high or low relative to other signals, etc. But the only difference between BNROM and AMROM is nametable mirroring, and several games for PAL NES are on AxROM.
1) the audio plays normally. it needs to be switched into during an NMI. so that code is running correctly, every frame, bankswitches and all. controllers (start button, mainly) also being read and responding.
2) the graphics don't display at all.
3) the whole thing resets at a time when it should not.
i would think it was just a problem with my code (likely) but it seems to be working on emulators and an AVS, and on PAL emulation. i can't test my NTSC machine because it gives me a blinking light, but the PAL machine is causing problems. wouldn't be surprised if the NTSC gave trouble too though.
I would also recommend putting a read/write breakpoint on all regions where memory access is unexpected. (e.g. $0800-1FFF, $2008-$3FFF, $4020-$7FFF)
The behaviour of FCEUX for the "open bus" regions where nothing is connected is especially different from a real NES (though Nintendulator gets this stuff correct). A well behaved program wouldn't be reading or writing there, though, under normal circumstances.
A lot of emulators will stick WRAM at $6000-7FFF at nearly all times, which can also mess with this area that's supposed to be open bus. Similarly flash carts might do something that modifies this behaviour as well.
Oh, and put FCEUX on "New PPU" mode if you haven't. This is much more accurate PPU behaviour.
i wonder if there isn't some strange PAL/powerpak/BNROM problem happening. i guess i'll make sure i'm not reading/writing from any strange addresses, but i don't see how or why i would be doing that.
Code: Select all
initPPU: bit PPU_STATUS @1: bit PPU_STATUS bpl @1 @2: bit PPU_STATUS bpl @2
Maybe you are attempting to do things too early? (Just a guess from somebody not very literate, mind you)
- Formerly WheelInventor
- Posts: 2032
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
If you're willing to let your unit go under the knife, desoldering, lifting or grounding pin 4 on the lockout chip is not only good for region unlocking but also increases the reliability considerably even if the consoles' connector is somewhat corroded or dirty.toggle switch wrote:i can't test my NTSC machine because it gives me a blinking ligh
To elaborate this, the screen is black but probably ought to be gray (ie $00) or rarely some other random colour if not initialized (which it is here) so i think it is displaying *something* (after all, there are 10 blacks)?toggle switch wrote:2) the graphics don't display at all.
...general question: the floodfill (ie "universal background colour") is still filling the screen with bg rendering turned off, right?
Graphics are displaying in nintendulator. fwiw the game behaves quite differently in both fceux and nintendulator in PAL mode (fceux: music ok but ingame movement jittery. nintendulator: music off but movement correct).rainwarrior wrote:the behaviour of FCEUX for the "open bus" regions where nothing is connected is especially different from a real NES (though Nintendulator gets this stuff correct
i've written some really sloppy inits on powerpak/pal +nrom/unrom and they're fine, for what it is worth. Without proper warmup the worst i've gotten is a bit of a rolling picture. toggle switchs' CNROM version of the game ran fine on powerpak/pal and i believe the init is the same on the BNROM version.na_th_an wrote:Neslib, which works correctly in PAL in real hardware and with bankswitching (I've tested GNROM-like and UNROM) [...] Maybe you are attempting to do things too early?
hmm, can't replicate this. nintendulator works fine for me, both music and movement. fceux looks a bit janky with the movement but i think it's not really intended as a PAL emulator and maybe needs some kinks worked out - i don't think the movement jitter is an issue with my code, i don't see how it could be. either way, neither one displays behavior that currently is bothering me.Graphics are displaying in nintendulator. fwiw the game behaves quite differently in both fceux and nintendulator in PAL mode (fceux: music ok but ingame movement jittery. nintendulator: music off but movement correct).
I do some things (larger number of banks, 4 nametables) that the emulators tend to support but aren't traditional BNROM features, so that may have something to do with it. I haven't spent any time debugging or testing further, but just thought it would be worth noting. (although it's just as likely that my issue is completely different than yours and I'm doing something dumb also.)
the only thing i can think is that i'm not sure if emulators start you off on a random bank? does anybody know of one that does? i'm pretty certain jumping to bank 0 happens pretty much immediately, but still.
PowerPak and FCEUX have no trouble supporting oversize BNROM (up to PowerPak's maximum of 4 Mbit) since second quarter 2011 when I released BNTest. Haunted: Halloween '85 and Lizard both use a 4 Mbit BNROM, as did early builds of the first volume of Action 53 before the specialized mapper was added to support STREEMERZ as the flagship title. The 4-screen I haven't tried though.gauauu wrote:I do some things (larger number of banks, 4 nametables) that the emulators tend to support but aren't traditional BNROM features, so that may have something to do with it.