BNROM - emulation vs real NES
Moderator: Moderators
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: BNROM - emulation vs real NES
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.
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.
Re: BNROM - emulation vs real NES
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.
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.
Re: BNROM - emulation vs real NES
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....
My games: http://www.bitethechili.com
- toggle switch
- Posts: 139
- Joined: Fri Sep 30, 2016 8:57 pm
Re: BNROM - emulation vs real NES
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.
not sure why the graphics don't appear, but hopefully it's something similar.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: BNROM - emulation vs real NES
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.
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.
Re: BNROM - emulation vs real NES
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.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.
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.
- toggle switch
- Posts: 139
- Joined: Fri Sep 30, 2016 8:57 pm
Re: BNROM - emulation vs real NES
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.every sprite movement is staggering as if every other or so update didn't happen, at least here.
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.
you can see the game here:You might be relying on some fine timing detail
https://forums.nesdev.com/viewtopic.php?f=33&t=16785
it'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.
Re: BNROM - emulation vs real NES
Oh, I didn't realize you were talking about this! So the problem appeared when converting from CNROM to BNROM? Weird.
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.we're not relying on crazy timing or doing anything remotely revolutionary. just trying to build an entertaining game using basic techniques.
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.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: BNROM - emulation vs real NES
The pal physics/time compensation was added after the currently available CNROM version.So the problem appeared when converting from CNROM to BNROM? Weird.
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.
- toggle switch
- Posts: 139
- Joined: Fri Sep 30, 2016 8:57 pm
Re: BNROM - emulation vs real NES
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.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.
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.
Last edited by toggle switch on Sat Mar 17, 2018 2:15 pm, edited 1 time in total.
- rainwarrior
- Posts: 8731
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: BNROM - emulation vs real NES
Yes, the last official powerpak mappers are only set up for 2 bits of latch.tepples wrote:The official mapper pack may still have the version limited to 1 Mbit.
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.)
- toggle switch
- Posts: 139
- Joined: Fri Sep 30, 2016 8:57 pm
Re: BNROM - emulation vs real NES
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.
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.
Last edited by toggle switch on Sat Mar 17, 2018 4:57 pm, edited 2 times in total.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: BNROM - emulation vs real NES
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)?
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)?
- toggle switch
- Posts: 139
- Joined: Fri Sep 30, 2016 8:57 pm
Re: BNROM - emulation vs real NES
i think those are both loaded from bank 2 (which, to be clear, is the third bank, since counting starts at zero!)
- toggle switch
- Posts: 139
- Joined: Fri Sep 30, 2016 8:57 pm
Re: BNROM - emulation vs real NES
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.
i think it smooths out the screen on my machine but i might be making it up.