can anybody elucidate the known differences between BNROM on an emulator (FCEUX, but willing to try others) vs on a real NES?
Only differences should be:
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.
i believe i use
Code:
noBusConflict:
lda #$01
sta noBusConflict+1
for all bankswitches. that should avoid all bus conflicts, right?
Quote:
BNROM is so simple that I'd be inclined to suspect uncharted 2A07/2C07 territory instead.
what do you mean by this?
Slight 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.
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).
RAM gets re-written to all zeroes at reset.
and all the banks contain the same reset code, which switches to bank 0 after the first vBlank.
Quote:
Slight 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.
the problem i'm having is that
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.
You can verify that your ROM isn't writing the NINA registers with a breakpoint.
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.
hmm. everything works fine in nintendulator, and in new PPU mode in FCEUX.
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.
I'd definitely recommend trying a few other emulators. If you can find one that reproduces the problem, you'll have a lot easier time debugging. (Particularly if that emulator had a debugger)
Edit: you beat me to it
Neslib, which works correctly in PAL in real hardware and with bankswitching (I've tested GNROM-like and UNROM), starts by setting to 0 all PPU_MASK & PPU_CTRL, then waits for a full frame:
Code:
initPPU:
bit PPU_STATUS
@1:
bit PPU_STATUS
bpl @1
@2:
bit PPU_STATUS
bpl @2
Then clears the palette, then clears VRAM, then clears RAM, sets SP, and then initializes the library. And only after everything has been set up, the NMI is enabled. Some extra stuff is performed before my code (which pages in PRG-ROM 0 / CHR-ROM 0 or whatever the startup configuration should be) even runs.
Maybe you are attempting to do things too early? (Just a guess from somebody not very literate, mind you)
toggle switch wrote:
i can't test my NTSC machine because it gives me a blinking ligh
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:
2) the graphics don't display at all.
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)?
...general question: the floodfill (ie "universal background colour") is still filling the screen with bg rendering turned off, right?
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
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).
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?
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.
Quote:
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).
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.
If it makes you feel any better, I just tried my big project (which eventually will target GTROM, but I've been testing with BNROM) on my powerpak and it didn't work right -- just a black screen with some weird graphical artifacts in the middle.
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.)
bummer! mostly, i'm frustrated by my inability to test it properly. once i have that 'working' i'll feel a bit better cause i'll have the chance to fix it.
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.
Most emulators seem to boot (not by design, but because of how uninitialized memory works on modern machines) from bank 0.
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.
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.
Thanks!
The test (when used on a powerpak on a PAL console) says only the first 128kB of PRG-ROM is available, so that's likely problem considering the rom file is 512kB:s which might mean this powerpak disclaimer:
"PAL compatibility has not been fully tested, only that it will run games." means something unfortunate in this case.
So, in effect the first 4 banks are mirrored, which explains why the intro "returns" to the title screen instead of level 1. Bank switching isn't broken - the banks are; when using powerpak on pal.
Below the post about BNTest is a post that Loopy's version of the BNROM mapper support file fixes it. The official mapper pack may still have the version limited to 1 Mbit.
I installed mapper packs on my own PowerPak's CF card in the following order: official, then
Loopy's, then
PowerMappers, then
thefox's port of kev's Action 53 mapper.
It's also with noting that Nova made a mapper file to support GTROM on the powerpak (on the off-chance that you're also using BNROM while developing a game targeting GTROM). I'll try to find the link to that when I'm at my real computer instead of my phone....
well that's almost certainly the reason why the reset occurs - right when we would be jumping into bank 4 for some data.
not sure why the graphics don't appear, but hopefully it's something similar.
i'll try using thefoxs' map22.map tomorrow or something, that should do the trick (my old cf reader/writer has extremely finnicky contacts and the usb terminal contacts are too small for me to see clearly, let alone resolder, so i need to get a new one and i've just had enough trying to hold it in a very specific angle
).
We're indeed targeting gtrom, but since toggle switch has an everdrive and i have a powerpak, we opted for bnrom during development which would work for both.
@toggle switch:
"jitter" may have been the wrong word, but for me, in fceux, every sprite movement is staggering as if every other or so update didn't happen, at least here. It behaves on nintendulator, so the game is most probably ok too, i just want to make sure on hardware. Both have differing oddities i'd credit to PAL emulation inaccuracies most likely, but better be sure.
FrankenGraphics wrote:
for me, in fceux, every sprite movement is staggering as if every other or so update didn't happen, at least here. It behaves on nintendulator, so the game is most probably ok too, i just want to make sure on hardware.
Even if it works on accurate emulators and real hardware, if something really crazy is happening in an emulator that runs the vast majority of games just fine, it may be a good idea to look into the problem.
You might be relying on some fine timing detail that causes obvious problems when accuracy is low, but may still cause less obvious/frequent symptoms when accuracy is high. If you can figure out where the problem is, you can probably make that part more resilient and compatible across different environments.
If you're doing something really precise and/or revolutionary that hasn't been thoroughly tested and documented before, then yeah, there's no way you'll get it to work everywhere, but if you're not doing anything "groundbreaking" at the technical level, programs *should* work on the most common emulators.
Quote:
every sprite movement is staggering as if every other or so update didn't happen, at least here.
personally i think it's just the difference between 60 updates a second and 50 that you're seeing. not everything multiplies cleanly by 1.2 or 0.8333333.
at least, if it looks on PAL the way it looks on
my computer, i'll be totally satisfied with that. maybe you're getting a different effect.
Quote:
You might be relying on some fine timing detail
you can see the game here:
https://forums.nesdev.com/viewtopic.php?f=33&t=16785it's a beginner's project - it's literally the first thing i've built outside of a basic scrolling demo and a bare bones sound engine. we're not relying on crazy timing or doing anything remotely revolutionary. just trying to build an entertaining game using basic techniques.
toggle switch wrote:
you can see the game here:
viewtopic.php?f=33&t=16785Oh, I didn't realize you were talking about this! So the problem appeared when converting from CNROM to BNROM? Weird.
Quote:
we're not relying on crazy timing or doing anything remotely revolutionary. just trying to build an entertaining game using basic techniques.
In this case, I maintain my opinion that it should be working on most emulators that generally run games well, and that even if it appears to work fine on accurate emulators and on real hardware, the bug cold still manifest itself under certain circumstances later. It may turn out to be 100% the emulator's fault, sure, but as long as there's a chance that your game is doing something unsafe/unreliable, I think this is worth looking into.
I don't know if this is good advice, but I'm the kind of developer that absolutely hates when bugs magically go away, because I can never be sure whether they were really eliminated or just obscured by some "fortunate" coincidence. When my programs aren't behaving correctly, I absolutely need to find and understand the reason, so I can fix it properly and be sure that other less obvious parts of the program aren't being affected by the problem too.
Quote:
So the problem appeared when converting from CNROM to BNROM? Weird.
The pal physics/time compensation was added after the currently available CNROM version.
Either way, i'll know a bit more about this tomorrow. Hopefully the more serious thing with the graphics loading is proven to be a powerpak .map-mets-PAL-console problem too.
Quote:
In this case, I maintain my opinion that it should be working on most emulators that generally run games well, and that even if it appears to work fine on accurate emulators and on real hardware, the bug cold still manifest itself under certain circumstances later.
i honestly don't believe there is a bug in the first place, at least not with my code. at worst you could say that the powerpak has an incomplete mapper implementation, or that by using 16 banks we've exceeded what is expected of a BNROM. shrug.
maybe what frankengraphics is experiencing on her machine is different than what i'm getting. but i'm not getting anything that i'd call a bug, just movement that isn't as silky as the 60hz version. no surprise there.
tepples wrote:
The official mapper pack may still have the version limited to 1 Mbit.
Yes, the last official powerpak mappers are only set up for 2 bits of latch.
Just in case it wasn't said yet in the thread, there does need to be a startup stub in every bank, and failing this creates a problem that might not manifest on a flash cart or emulator, but is critical for an actual discrete mapper board. (Same deal with bus conflicts.)
yeah each bank has waits for vblank, then moves over to bank zero around the same time it empties out RAM.
for a while i thought i may have screwed up something there - after all, emulators don't properly select a random bank at reset for some reason (seems like an easy enough thing to implement, and important too, at least for development). but that wouldn't explain why the banks appear to work in emulation. if stuff wasn't aligned properly, then all my bank calls would fail too, and we know that they aren't, since the audio is being read every NMI, and also can read controller presses, which occur in another bank.
In lieu of testing on hardware for now, i recorded an avi to see if i could bring closure to the staggering movement thing. The avi plays decidedly smoother than when playing. So it seems that for some reason, FCEUX in PAL mode has a display problem (maybe frame rate related?) on
this particular pc. I expect the avi to be wysiwyg compared to my pal console in terms of smoothness.
As a side, the extended vblank of PAL happens to do this game subtle favours in some places. Boss fights and the busier rooms are rock solid.
Which bank is title screen and intro graphics data (including palettes loaded from)?
i think those are both loaded from bank 2 (which, to be clear, is the third bank, since counting starts at zero!)
trying slowing your speed down to 75 or 50% and then bring it back up to 100 and see if that helps.
i think it smooths out the screen on my machine but i might be making it up.
hah, i just realized that all the palette data is also in bank 4, so that solves that.
thanks everyone.
To confirm, it works great with the "powermapper" package.
No apparent bugs following the bnrom conversion that i can see.
great news.
seriously, thanks to everybody who responded, i know these questions are hardly fun or interesting to answer.