Just trying to figure out what nestopia could be doing wrong here. In the Japanese version of Burai Fighter the status bar at the bottom of the screen is as it should be. On Burai Fighter american version you get this:
Attachment:
9a35d62c-f9ee-11e3-8c2f-025d77e34ca7.png [ 2.83 KiB | Viewed 4266 times ]
Also on ninja gaiden (u) you also have a chunk of the moon missing in the first cutscene while in the japanese version you do not. Any chance these two games with issues could be related. Weird how the japanese versions work great and the us not so great. I backtracked through all the nestopia releases i could and NOT ONE has ever played burai fighter correctly with the whole status bar showing. Seems like something is clipping the edges off.
Maybe some other devs can possibly shed some light on this issue. I also wonder if this has anything to do with some of the timer being clipped on hard drivin as well.
*Spitfire_NES* wrote:
Just trying to figure out what nestopia could be doing wrong here. In the Japanese version of Burai Fighter the status bar at the bottom of the screen is as it should be. On Burai Fighter american version you get this:
Attachment:
9a35d62c-f9ee-11e3-8c2f-025d77e34ca7.png
Also on ninja gaiden (u) you also have a chunk of the moon missing in the first cutscene while in the japanese version you do not. Any chance these two games with issues could be related. Weird how the japanese versions work great and the us not so great. I backtracked through all the nestopia releases i could and NOT ONE has ever played burai fighter correctly with the whole status bar showing. Seems like something is clipping the edges off.
Maybe some other devs can possibly shed some light on this issue. I also wonder if this has anything to do with some of the timer being clipped on hard drivin as well.
...........You are joepogo ?
Compare fceumm and fceux the ppu....
*Spitfire_NES* wrote:
Just trying to figure out what nestopia could be doing wrong here. In the Japanese version of Burai Fighter the status bar at the bottom of the screen is as it should be. On Burai Fighter american version you get this:
Attachment:
9a35d62c-f9ee-11e3-8c2f-025d77e34ca7.png
Looks like the 2nd scanline IRQ is firing too early. Maybe the game depends on a specific MMC3 IRQ behavior? Just a random guess. puNES 0.63 has the exact same problem
Quote:
Also on ninja gaiden (u) you also have a chunk of the moon missing in the first cutscene while in the japanese version you do not. Any chance these two games with issues could be related. Weird how the japanese versions work great and the us not so great. I backtracked through all the nestopia releases i could and NOT ONE has ever played burai fighter correctly with the whole status bar showing. Seems like something is clipping the edges off.
I doubt this is related to the first issue. In this case, a single byte in the attribute table gets messed up for some reason. Same bug shows up in Nintendulator, with slightly different results. The game may be doing something unorthodox, like writing to PPU with rendering on, causing each emulator to interpret the situation slightly differently.
thefox wrote:
*Spitfire_NES* wrote:
Just trying to figure out what nestopia could be doing wrong here. In the Japanese version of Burai Fighter the status bar at the bottom of the screen is as it should be. On Burai Fighter american version you get this:
Attachment:
9a35d62c-f9ee-11e3-8c2f-025d77e34ca7.png
Looks like the 2nd scanline IRQ is firing too early. Maybe the game depends on a specific MMC3 IRQ behavior? Just a random guess. puNES 0.63 has the exact same problem
Quote:
Also on ninja gaiden (u) you also have a chunk of the moon missing in the first cutscene while in the japanese version you do not. Any chance these two games with issues could be related. Weird how the japanese versions work great and the us not so great. I backtracked through all the nestopia releases i could and NOT ONE has ever played burai fighter correctly with the whole status bar showing. Seems like something is clipping the edges off.
I doubt this is related to the first issue. In this case, a single byte in the attribute table gets messed up for some reason. Same bug shows up in Nintendulator, with slightly different results. The game may be doing something unorthodox, like writing to PPU with rendering on, causing each emulator to interpret the situation slightly differently.
Thanks fox for answering. Please excuse my noobness, but does it have anything to do with this at least regarding the burai figher issue? I think this discovery will fix mickeys safari in letterland no doubt as well with the status bar being jumpy.
viewtopic.php?f=3&t=10439
*Spitfire_NES* wrote:
Thanks fox for answering. Please excuse my noobness, but does it have anything to do with this at least regarding the burai figher issue? I think this discovery will fix mickeys safari in letterland no doubt as well with the status bar being jumpy.
No idea. Every emulator I have tried has the same problem with Mickey (puNES, Nintendulator, Nestopia).
sorry i did not clarify what i was asking better.
I guess what i mean is regarding the link i posted, is this something that will benefit the burai fighter issue? Seems like james found undocumented behavior but maybe that is only regarding the rambo mapper. Nestopia is hard to navigate through for me, but maybe the i need to be looking at the mmc3 code, since i think burai fighter is mmc3 IIRC.
That linked behavior won't help with this game.
Mickey's Safari in Letterland works fine with nemulator. It requires really precise IRQ timing.
James wrote:
That linked behavior won't help with this game.
Mickey's Safari in Letterland works fine with nemulator. It requires really precise IRQ timing.
Thank you james, thats what i was thinking. Im going to find a way to get these fixes in for those 3 above mentioned games. As far as burai fighter goes, this will prob help me:
http://sourceforge.net/p/fceultra/bugs/382/ill start from here since these 2 issues seem to be the same, or used to be until fce fixed it. Just trying to pinpoint exactly what the issue is regarding burai fighter first, thats all.
and by the way GREAT WORK on everything you have done for the emulation scene james!
thefox wrote:
No idea. Every emulator I have tried has the same problem with Mickey (puNES, Nintendulator, Nestopia).
Strange, I thought I had fixed this problem several versions ago. Thefox which version of puNES have you tried? The latest (0.89)?
FHorse wrote:
thefox wrote:
No idea. Every emulator I have tried has the same problem with Mickey (puNES, Nintendulator, Nestopia).
Strange, I thought I had fixed this problem several versions ago. Thefox which version of puNES have you tried? The latest (0.89)?
Indeed, it's working fine in puNES. But Burai Fighter isn't.
FHorse wrote:
thefox wrote:
No idea. Every emulator I have tried has the same problem with Mickey (puNES, Nintendulator, Nestopia).
Strange, I thought I had fixed this problem several versions ago. Thefox which version of puNES have you tried? The latest (0.89)?
Yeah sorry, I was using an old version.
*Spitfire_NES* wrote:
and by the way GREAT WORK on everything you have done for the emulation scene james!
Thanks!
Burai Fighter is broken in nemulator too. I'll look into it when I have some time.
James wrote:
*Spitfire_NES* wrote:
and by the way GREAT WORK on everything you have done for the emulation scene james!
Thanks!
Burai Fighter is broken in nemulator too. I'll look into it when I have some time.
sweet! in the meantime i decided to start with ninja gaiden diffing code between 1.39 and 1.40, in 1.39 and have a question for whoever can or may put some light on this.
At initial glance at the code, the mmc1 mapper was not modified going into 1.39 to 1.40, in other words the code was left unchanged, regarding the missing chunk of moon should i move efforts to diff code to the ppu instead? This does have changes going from 1.39 to 1.40, im not sure where else he could have done something to mess up the intro like that., also he did make some changes to the apu as well going from 1.39 to 1.40.
Burai Fighter has two MMC3 IRQs per frame: one at the top of the status bar and another at the bottom. In between, there are a couple of reads to PPU memory > $3000 via $2006/$2007. These reads, if not properly mirrored to $2xxx, will cause A12 to go high and clock the IRQ counter, making the second IRQ fire a couple of scanlines too early. I fixed this mirroring in my emulator and Burai Fighter looks good now:
Thank you james for sharing that. Im going to try to implement this into nestopia. Pm sent.
It sounds easy to do and id like to get this fix into nestopia as well. Thank you for sharing this info. Im working on trying to sort out these 3 games as we speak.
Where exactly in the NES hardware does this mirroring from $3000 to $2000 takes place? I thought $3000 had PA12 high, just like $1000, likewise clocking the counter. Is it inside the PPU? Inside the MMC3? Or, as I thought, only on the CHR ROM part of the board?
EDIT: fixed typo
in nemu...
fixed is
if(address & 0x1000)
irq.address =4;===>irq.address =8;
?
tepples wrote:
I thought $3000 had PA12 high, just like $2000
You mean like $1000, right? I'm not sure what you mean by "the CHR ROM part of the board".
Check out this post:
viewtopic.php?t=3657&view=next#p27891. In my emulator, palette writes were already not being put on the bus, so this seems to be the same issue (I may have been thinking about Mickey's Adventure in Numberland, not Safari in Letterland, when I mentioned it needing precise IRQ timing...)
James wrote:
tepples wrote:
I thought $3000 had PA12 high, just like $2000
You mean like $1000, right? I'm not sure what you mean by "the CHR ROM part of the board".
Check out this post:
viewtopic.php?t=3657&view=next#p27891. In my emulator, palette writes were already not being put on the bus, so this seems to be the same issue (I may have been thinking about Mickey's Adventure in Numberland, not Safari in Letterland, when I mentioned it needing precise IRQ timing...)
you update ppu or mmc3 irq?
zxbdragon wrote:
you update ppu or mmc3 irq?
PPU
James wrote:
zxbdragon wrote:
you update ppu or mmc3 irq?
PPU
I see Nintendulator is fixed mmc3 irq
Can you share your fix part ?
Hey zxbdragon here is one thing that james helped me with that DID fix mickey's safari in letterland but not burai fighter, maybe you can help us zxbdragon get burai fighter fixed.
in NstPPU.cpp
change:
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
this will fix mickeys safari in letterland, now we need to figure out burai fighter. Thanks for this code james as well james and allowing me to share!
James wrote:
tepples wrote:
I thought $3000 had PA12 high, just like $2000
You mean like $1000, right?
My bad.
Quote:
I'm not sure what you mean by "the CHR ROM part of the board".
I might have said things wrong. Let me try again:
Some chips see accesses to $3000-$3EFF as accesses to $2000-$2EFF. Examples of this include CIRAM (the nametable memory) because PA12 isn't connected. Others see accesses to $3000-$3EFF as accesses to $1000-$1EFF (the second pattern table). Examples of this include the MMC3 itself because the TLSROM hack depends on it ignoring PA13.
Quote:
In my emulator, palette writes were already not being put on the bus
If that's the issue, that would explain it. A test ROM for whether the MMC3's PIT is clocked by writes to $3000-$3EFF but not $3F00-$3FFF might help.
*Spitfire_NES* wrote:
Hey zxbdragon here is one thing that james helped me with that DID fix mickey's safari in letterland but not burai fighter, maybe you can help us zxbdragon get burai fighter fixed.
in NstPPU.cpp
change:
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
this will fix mickeys safari in letterland, now we need to figure out burai fighter. Thanks for this code james as well james and allowing me to share!
thank you james and *Spitfire_NES*
*Spitfire_NES* wrote:
Hey zxbdragon here is one thing that james helped me with that DID fix mickey's safari in letterland but not burai fighter, maybe you can help us zxbdragon get burai fighter fixed.
in NstPPU.cpp
change:
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
this will fix mickeys safari in letterland, now we need to figure out burai fighter. Thanks for this code james as well james and allowing me to share!
thank you james and *Spitfire_NES*
I have been concerned burai fighter,
yes, the mickeys issue and the burai fighter issue seem to be related.
tepples wrote:
Others see accesses to $3000-$3EFF as accesses to $1000-$1EFF (the second pattern table). Examples of this include the MMC3 itself because the TLSROM hack depends on it ignoring PA13.
I still might not be following what you're saying, but all of the TLSROM (and other MMC3) games I tested seem to work fine with this fix. Do you know of any game that's dependent on this behavior?
Was just thinking about this a bit more. I've only implemented this fix on $2006/$2007 access, not on normal accesses during rendering. So maybe this behavior only applies then...
edit: It must only apply then. The PPU doesn't access $3xxx during rendering (see Brad Taylor's 2C02 reference).
James wrote:
Was just thinking about this a bit more. I've only implemented this fix on $2006/$2007 access, not on normal accesses during rendering. So maybe this behavior only applies then...
is this something i need to check for on nestopia's end for james? Trying to figure out anything i can to have accurate emulation.
*Spitfire_NES* wrote:
is this something i need to check for on nestopia's end for james? Trying to figure out anything i can to have accurate emulation.
I don't know. You should probably hold off until there is a definitive answer to how this works (which will likely involve tests on real hardware).
ok will do. In the meantime i will mess around with what i have so far and see if anything turns up. Maybe someone can come along who might understand nestopia better than i and at least lend a hand to maybe help me figure out burai fighter.
thanks james!
Hi *Spitfire_NES*
I was wondering how you went implementing a fix in Nestopia.
So, did you manage to fix this ?
Cheers
hi oxyandy,
Presently at an impasse. The code posted on page 2 of this thread is where everything is at. Mickeys has apparently been fixed thanks to james help!.
The burai fighter issue has not been fixed. Do you have any ideas that may be of help?
Someone who understands the structure better of nestopias code might be able to do better than me. These 2 issues seem to be related though.
zxbdragon wrote:
in nemu...
fixed is
if(address & 0x1000)
irq.address =4;===>irq.address =8;
?
zxbdragon is this code referring to mickeys or burai fighter?
edit*** also referring back to some pms maybe we need to check if nestopia is putting palette writes on the bus.
*Spitfire_NES* wrote:
zxbdragon wrote:
in nemu...
fixed is
if(address & 0x1000)
irq.address =4;===>irq.address =8;
?
zxbdragon is this code referring to mickeys or burai fighter?
edit*** also referring back to some pms maybe we need to check if nestopia is putting palette writes on the bus.
???
this code referring to mickeys or burai fighter in other emu
thank you for replying zxbdragon. I was just asking if that block of code you were asking about was referring to mickey's or burai fighter.
Same result of the other guy. It fixes Mickey, but not Burai FIghter. I don't know about $2006, since it's a write-only register.
so just to clarify zepper, you tried this fix with the same result on a different emulator?
In my own emulator, of course. Fixes Mickey in Letterland, but not Burai FIghter. I understand on $2007 reads and writes, but what about $2006???
Zepper wrote:
In my own emulator, of course. Fixes Mickey in Letterland, but not Burai FIghter. I understand on $2007 reads and writes, but what about $2006???
looks like your emulator and nestopia share the same problem then, so what will work for yours will prob work for nestopia too. Will be interesting to see for sure. Thanks for clarifying.
Im digging back through what i have on the issue to see if i can find anything of relevance.
Zepper wrote:
In my own emulator, of course. Fixes Mickey in Letterland, but not Burai FIghter. I understand on $2007 reads and writes, but what about $2006???
$2007 Reads,PPU is death.
I think
Well, at $2007 read, the ppu address is given by loopy_v & 0x3FFF, since it ignores the higher bit ($4000). But how's supposed to handle the ppu mirroring $3000-3EFF to $2000-2EFF???
The PPU doesn't do that mirroring. The CIRAM does that because it's not connected to A12 in the vast majority of boards.
tepples wrote:
The PPU doesn't do that mirroring. The CIRAM does that because it's not connected to A12 in the vast majority of boards.
hey tepples, just to clarify, is the CIRAM related to burai fighter?
Warning! The following code/description respects my ppu gfx engine/rendering method and an idea from Disch, be sure to read this post. A few things might be "different" for a few of you. I have
no clue about a proper fix for Burai Fighter. Works on Nintendulator, but not on Nestopia. It doesn't matter the MMC3 PPU bus value, the score is still clipped, much like what happened with Gradius II (J) ages ago, but that's mapper 25. My only finding was about Mickey in Letterland. It's 1 scanline early in puNES by seeing a screenshot posted here. A way for fixing it relies on $2006 second write. The MMC3 PPU bus should take
loopy_v & 0x3FFF, and the mirroring must occur. In short words, if( ppu_bus >= 0x2000) ppu_bus = 0 (no rising).
*Spitfire_NES* wrote:
tepples wrote:
The PPU doesn't do that mirroring. The CIRAM does that because it's not connected to A12 in the vast majority of boards.
hey tepples, just to clarify, is the CIRAM related to burai fighter?
CIRAM is just a name I found somewhere for that 2K VRAM chip on the motherboard, commonly used for nametables. And according to
its entry in NesCartDB,
Burai Fighter uses the TEROM board, which doesn't do anything funny with the nametables the way
After Burner and
Namco 129 and 163 do.
Ah, okay.
thanks for the clarification tepples. Just trying to sort out what the issue is exactly, or could be. It does not make any sense to me how the burai fix fixes mickey but not the game it was originally intended to.
What in the heck are we missing here lol.
Easy: fixes Nestopia and we'll get the answer.
Hacking the IRQ counter latch with +2 fixes the game. Other than that, I have no idea.
Zepper wrote:
Easy: fixes Nestopia and we'll get the answer.
Hacking the IRQ counter latch with +2 fixes the game. Other than that, I have no idea.
thanks zepper. Just so i understand:
this was the block of code added to nestopia to fix burai (but ended up fixing mickey)
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
so are you saying if i add +2 to this this will fix burai, (at the moment labeled a hack i take it) If i add +2 wont this then break mickeys in effect and other games that might rely on this behavior? Sorry to sound like a noob, i just want to understand your statement completely, thats all.
*Spitfire_NES* wrote:
Zepper wrote:
Easy: fixes Nestopia and we'll get the answer.
Hacking the IRQ counter latch with +2 fixes the game. Other than that, I have no idea.
thanks zepper. Just so i understand:
this was the block of code added to nestopia to fix burai (but ended up fixing mickey)
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
so are you saying if i add +2 to this this will fix burai, (at the moment labeled a hack i take it) If i add +2 wont this then break mickeys in effect and other games that might rely on this behavior? Sorry to sound like a noob, i just want to understand your statement completely, thats all.
mmc3. wirte c000
data+2
irq.unit.SetLatch( data+2 );
....
Ninja Gaiden .....
FetchAttribute?
zxbdragon wrote:
*Spitfire_NES* wrote:
Zepper wrote:
Easy: fixes Nestopia and we'll get the answer.
Hacking the IRQ counter latch with +2 fixes the game. Other than that, I have no idea.
thanks zepper. Just so i understand:
this was the block of code added to nestopia to fix burai (but ended up fixing mickey)
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
so are you saying if i add +2 to this this will fix burai, (at the moment labeled a hack i take it) If i add +2 wont this then break mickeys in effect and other games that might rely on this behavior? Sorry to sound like a noob, i just want to understand your statement completely, thats all.
mmc3. wirte c000
data+2
irq.unit.SetLatch( data+2 );
....
have you tried this fix zxbdragon?
have you tried this fix zxbdragon?[/quote]
Yes, I tried on the official code .Burai Fighter.
but the problem is that nmt ninja Gaiden, nestopia 1.39-->1.40, puu bug
What's wrong with Ninja Gaiden??
Zepper wrote:
What's wrong with Ninja Gaiden??
Attachment:
24.jpg [ 32.85 KiB | Viewed 2015 times ]
Zepper wrote:
What's wrong with Ninja Gaiden??
latch+2,How much influence MMC3 GAME
Zepper wrote:
See yourself.
thank you,I build nestopia to tested!
Too many mmc3 game, do not know will not affect other games
This is not the right way to fix it. You will break other games.
James wrote:
This is not the right way to fix it. You will break other games.
yes,I'll worry about this
James wrote:
This is not the right way to fix it. You will break other games.
Obviously.
Well, I don't know what's wrong with Burai Fighter, and that was the only "hint" I could get for the problem.
MMC3 IRQ counter should not be clocked by accesses >$2FFF. Filter those in your mapper or ppu code and burai fighter should work correctly.
I already did without success.
zxbdragon wrote:
Ninja Gaiden .....
FetchAttribute?
yes but how to fix is very hard to pinpoint.
@James
Interesting, i never knew about that. After checking im sure nestopia is doing that too. So it seems like this is potential solution or problem. lol. Is there no way to add an exception for this without breaking the other games? Obviously i want to do this the right way if i can and im sure the same for zepper too.
I just find it amusing both emus have the same issue. zxbdragon id like to add the source change you tried to fix burai fighter if you dont mind posting it just to see what breaks other games. As for ninja gaiden i dont know how to track the ppu bug in the table.
*Spitfire_NES* wrote:
zxbdragon wrote:
Ninja Gaiden .....
FetchAttribute?
yes but how to fix is very hard to pinpoint.
@James
Interesting, i never knew about that. After checking im sure nestopia is doing that too. So it seems like this is potential solution or problem. lol. Is there no way to add an exception for this without breaking the other games? Obviously i want to do this the right way if i can and im sure the same for zepper too.
I just find it amusing both emus have the same issue. zxbdragon id like to add the source change you tried to fix burai fighter if you dont mind posting it just to see what breaks other games. As for ninja gaiden i dont know how to track the ppu bug in the table.
Both BUG, I have not corrected the problem only preliminary know , they did not know where the solutions in nestiopia!
James wrote:
MMC3 IRQ counter should not be clocked by accesses >$2FFF. Filter those in your mapper or ppu code and burai fighter should work correctly.
This fix
on PPU $2006 second write makes Mickey in Letterland to work correctly, its scorebar has the correct position now. Even puNES has a bad scorebar for that game.
About Burai Fighter, I have no clue - I already did what you said, but nothing happened. The IRQ is clocked like blargg explains in his test ROMs - during the HBlank on cycles 260,268... when BG is at $0000 and sprites at $1000 (standard). Any other setting I put on IRQs to try a fix for Burai Fighter messes up the game.
Zepper wrote:
James wrote:
MMC3 IRQ counter should not be clocked by accesses >$2FFF. Filter those in your mapper or ppu code and burai fighter should work correctly.
This fix
on PPU $2006 second write makes Mickey in Letterland to work correctly, its scorebar has the correct position now. Even puNES has a bad scorebar for that game.
About Burai Fighter, I have no clue - I already did what you said, but nothing happened. The IRQ is clocked like blargg explains in his test ROMs - during the HBlank on cycles 260,268... when BG is at $0000 and sprites at $1000 (standard). Any other setting I put on IRQs to try a fix for Burai Fighter messes up the game.
hey james, with this being said, is there something else the both of us could be missing here you think? Seems like it would and should work. Very odd to say the least...
You're going to have to get your hands dirty. Run it in a debugger and break on any PPU accesses >= 0x3000 then trace it out from there.
Let me recap the IRQ thing (assuming the standard PPU setup):
- the standard setup is background tiles at PPU $0000 and sprites at PPU $1000;
- this makes A12 rising during the HBlank at every 8 cycles, starting at 260th;
- according to the test ROMs, A12 should rise at PPU dot 260.
Also, the IRQ counter is clocked when $2006/2007 is accessed.
Well, my emu uses a different gfx engine - that's might be the problem, but I dunno.
You should use the following logic: clock the IRQ counter when A12 transitions from low to high after being low for a sufficient period of time (I use 5 CPU cycles). This will generally happen at PPU cycle 260, but it's easier to deal with the edge cases by simplifying the conditions for clocking the counter.
This means, of course, that you need to make sure that you're accessing PPU memory at all of the right times: PPU fetches during rendering (especially sprite fetches starting at cycle 260) and accesses via $2006/$2007.
Blocking the IRQ if the PPU address is >= 0x3000 breaks all the games here in my emu.
Perhaps the MMC3 can see accesses to $3000-$3EFF (mirror of nametables) but not $3F00 through $3FFF (palette, in internal CGRAM)
I've been lurking on this thread a while due to having these same issues in my emulator. I've resolved the glitch in Burai Fighter (using a completely different fix than the one described previously) and Ninja Gaiden, but I'm still having trouble with Safari in Letterland and Goal! Two, which also has a shaky status bar that seems to be dependant on the last fine vertical scroll value when vblank starts.
tepples wrote:
Perhaps the MMC3 can see accesses to $3000-$3EFF (mirror of nametables) but not $3F00 through $3FFF (palette, in internal CGRAM)
I tested this in Visual 2C02, and it puts bits 0-13 of loopy_v (or vramaddr_v as Visual 2C02 calls it) on the address bus for any read or write via $2007 when not rendering no matter what the value of loopy_v is (while rendering the bus is controlled by the rendering logic, and therefore not directly affected by the change to loopy_v). This also happens when setting loopy_v via $2006 (again, only when not rendering), when rendering is disabled via $2001, and after rendering ends (cycle 0 of scanline 240). If this reflects the PPU's actual behavior, then palette accesses can clock the IRQ counter.
I had to fix my code so that $2006 and $2007 only touched the address bus when the PPU wasn't rendering (Nestopia doesn't do this correctly either). I also had to change the behavior of $2007 accesses while rendering so that the horizontal and vertical scroll were both always incremented (Nestopia UE increments one or the other based on bit 2 of $2000). ulfalizer traced Visual 2C02 and figured out why this happens
here and documented it in the
wiki.
I've modified Nestopia UE to address the above issues and Burai Fighter works correctly. You can see the diff of my changes in my
github fork.
The glitch in Ninja Gaiden's intro is caused by
extra $2007 reads due to DPCM DMA. I had this exact same glitch in my emulator, and disabling the extra reads for $2007 "fixed" it. I got the same results in Nestopia with a similar change to Apu::Dmc::DoDMA() in NstApu.cpp. I haven't dug any further into this one yet.
perilsensitive wrote:
I've been lurking on this thread a while due to having these same issues in my emulator. I've resolved the glitch in Burai Fighter (using a completely different fix than the one described previously) and Ninja Gaiden, but I'm still having trouble with Safari in Letterland and Goal! Two, which also has a shaky status bar that seems to be dependant on the last fine vertical scroll value when vblank starts.
tepples wrote:
Perhaps the MMC3 can see accesses to $3000-$3EFF (mirror of nametables) but not $3F00 through $3FFF (palette, in internal CGRAM)
I tested this in Visual 2C02, and it puts bits 0-13 of loopy_v (or vramaddr_v as Visual 2C02 calls it) on the address bus for any read or write via $2007 when not rendering no matter what the value of loopy_v is (while rendering the bus is controlled by the rendering logic, and therefore not directly affected by the change to loopy_v). This also happens when setting loopy_v via $2006 (again, only when not rendering), when rendering is disabled via $2001, and after rendering ends (cycle 0 of scanline 240). If this reflects the PPU's actual behavior, then palette accesses can clock the IRQ counter.
I had to fix my code so that $2006 and $2007 only touched the address bus when the PPU wasn't rendering (Nestopia doesn't do this correctly either). I also had to change the behavior of $2007 accesses while rendering so that the horizontal and vertical scroll were both always incremented (Nestopia UE increments one or the other based on bit 2 of $2000). ulfalizer traced Visual 2C02 and figured out why this happens
here and documented it in the
wiki.
I've modified Nestopia UE to address the above issues and Burai Fighter works correctly. You can see the diff of my changes in my
github fork.
The glitch in Ninja Gaiden's intro is caused by
extra $2007 reads due to DPCM DMA. I had this exact same glitch in my emulator, and disabling the extra reads for $2007 "fixed" it. I got the same results in Nestopia with a similar change to Apu::Dmc::DoDMA() in NstApu.cpp. I haven't dug any further into this one yet.
Great , so you are nestopia
zxbdragon wrote:
Great , so you are nestopia
rdanbrook maintains Nestopia UE, not me. I do use it on occasion however, so I created a github fork for sharing any fixes to bugs I might find. I don't do any real development on it. The main repository is at
https://github.com/rdanbrook/nestopia. My own emulator is currently unnamed and unreleased, although I expect that to change Real Soon Now.
Thank you for your valuable input perilsensitive and also thank you for posting the fix for burai fighter as well.
I sent you a pm by the way as i am curious about something else you said regarding ninja gaiden and figured it would be easier to pm you as to not derail the thread.
I would have never guessed in a million years that the problem with ninja gaiden (U) would be something like that. Thats why im a noob though, and its great to see the community come together and share fixes, information and the like.
Ive learned a lot from everyone and appreciate anyone who has taken the time to post their thoughts on anything i have ever asked.
sorry for the double post just wanted to add this real quick. I merged in your fix for burai fighter, but i noticed this overwrites james fix for mickey's in nstppu.cpp he shared a while back.
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
This part was overwritten so mickeys return back to the shaky status bar. Is there a way to put this back in for both games to coexist peacefully?
*Spitfire_NES* wrote:
sorry for the double post just wanted to add this real quick. I merged in your fix for burai fighter, but i noticed this overwrites james fix for mickey's in nstppu.cpp he shared a while back.
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
This part was overwritten so mickeys return back to the shaky status bar. Is there a way to put this back in for both games to coexist peacefully?
Integration code
if (!(regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED) ||
(scanline == SCANLINE_VBLANK)) {
UpdateAddressLine(scroll.address & 0x3fff);
}
to UpdateScrollAddressLine;
*Spitfire_NES* wrote:
sorry for the double post just wanted to add this real quick. I merged in your fix for burai fighter, but i noticed this overwrites james fix for mickey's in nstppu.cpp he shared a while back.
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
This part was overwritten so mickeys return back to the shaky status bar. Is there a way to put this back in for both games to coexist peacefully?
I actually eliminated UpdateScrollAddressLine() in my patch because it doesn't change the value of io.address, which is the value currently on the address bus. It really should though, as the actual bus value does change according to Visual 2C02. Since UpdateAddressLine already does that (and it seems the point of UpdateScrollAddressLine() was to *not* update the bus), it didn't make sense to leave it in.
As for the shaky status bar in Safari in Letterland, the fix James posted requires that the PPU never put addresses >= $3000 on the address bus (specifically, he forces A12 to 0 for addresses in that range before putting them on the bus, preventing the counter from being clocked), but that doesn't seem to match what Visual 2C02 does so I didn't include that change in my patch. The point of my patch was to show that the problem with Burai Fighter had a different (although somewhat related) root cause, the fix for which didn't require any special handling of $3000-$3FFF.
You could integrate the two patches by making a similar change to the one James made in his post, but instead of doing it to UpdateScrollAddressLine() (which no longer exists) do it directly to the address passed to UpdateAddressLine() in the implementations of $2006 and $2007. I'm too lazy to do this myself though.
It may (or may not) be worth noting that Safari in Letterland
uses an MC-ACC, which James has shown has
similar but different IRQ behavior to that of the MMC3. The difference James documented in that thread doesn't really make a difference for Safari in Letterland, but it makes me wonder if there are other differences we're missing that do. :-/
in NstApu.cpp 2138
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 2 : 3) );
}
to
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 3 : 4) );
}
Attachment:
[[)$6TQ]WWWJR@[G}554ESY.jpg [ 137.24 KiB | Viewed 2233 times ]
The need to observe and test
zxbdragon wrote:
in NstApu.cpp 2138
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 2 : 3) );
}
to
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 3 : 4) );
}
This won't work; it prevents the attribute glitch but breaks DMC DMA timing. For example, the sprdma_and_dmc_dma test roms hang before producing output with this change, which makes DMA take one extra cycle.
blargg demonstrated that at most DMC DMA will steal 3 cycles if it falls on a write cycle and 4 if it falls on a read. The first 2 cycles on a write or 3 cycles on a read are where the CPU is paused, doing nothing. The last cycle is the actual DMA transfer; the CPU is still paused but the DMA unit is reading from memory. Your change adds an extra cycle before the transfer starts, making DMA now steal 4 cycles on a write and 5 cycles on a read. This may break games that require precise DMC DMA timing.
perilsensitive wrote:
zxbdragon wrote:
in NstApu.cpp 2138
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 2 : 3) );
}
to
if (!readAddress)
{
cpu.StealCycles( cpu.GetClock(cpu.IsWriteCycle(clock) ? 3 : 4) );
}
This won't work; it prevents the attribute glitch but breaks DMC DMA timing. For example, the sprdma_and_dmc_dma test roms hang before producing output with this change, which makes DMA take one extra cycle.
blargg demonstrated that at most DMC DMA will steal 3 cycles if it falls on a write cycle and 4 if it falls on a read. The first 2 cycles on a write or 3 cycles on a read are where the CPU is paused, doing nothing. The last cycle is the actual DMA transfer; the CPU is still paused but the DMA unit is reading from memory. Your change adds an extra cycle before the transfer starts, making DMA now steal 4 cycles on a write and 5 cycles on a read. This may break games that require precise DMC DMA timing.
You find a better solution ?
perilsensitive wrote:
I tested this in Visual 2C02...while rendering the bus is controlled by the rendering logic, and therefore not directly affected by the change to loopy_v)
Nice job digging into this!
perilsensitive wrote:
It may (or may not) be worth noting that Safari in Letterland uses an MC-ACC, which James has shown has similar but different IRQ behavior to that of the MMC3. The difference James documented in that thread doesn't really make a difference for Safari in Letterland, but it makes me wonder if there are other differences we're missing that do. :-/
I played around with this a bit, but didn't have much luck either. It'll be interesting to find out what the issue is here... I'll try to take a look at it on the hardware sometime soon.
zxbdragon wrote:
You find a better solution ?
I don't have a solution yet. Every emulator that implements these extra reads caused by DMA has similar glitches, so *nobody* has a solution yet. You could disable the extra reads altogether, although this would still be a hack. No games depend on this behavior, and many emulators simply don't implement it at all (FCEUX, for example). It is of interest to NES developers though, especially when it causes extra reads of the controller ports.
You could do something like this in NstApu.cpp to disable the reads if the glitch really bothers you that much:
Code:
diff --git a/source/core/NstApu.cpp b/source/core/NstApu.cpp
index cf1f3df..cd14e6c 100644
--- a/source/core/NstApu.cpp
+++ b/source/core/NstApu.cpp
@@ -2137,19 +2137,19 @@ namespace Nes
{
cpu.StealCycles( cpu.GetClock(3) );
}
- else
- {
- NST_DEBUG_MSG("DMA/Read conflict!");
+ // else
+ // {
+ // NST_DEBUG_MSG("DMA/Read conflict!");
- cpu.StealCycles( cpu.GetClock(1) );
+ // cpu.StealCycles( cpu.GetClock(1) );
- if ((readAddress & 0xF000) != 0x4000)
- cpu.Peek( readAddress );
+ // if ((readAddress & 0xF000) != 0x4000)
+ // cpu.Peek( readAddress );
- cpu.StealCycles( cpu.GetClock(1) );
- cpu.Peek( readAddress );
- cpu.StealCycles( cpu.GetClock(1) );
- }
+ // cpu.StealCycles( cpu.GetClock(1) );
+ // cpu.Peek( readAddress );
+ // cpu.StealCycles( cpu.GetClock(1) );
+ // }
dma.buffer = cpu.Peek( dma.address );
cpu.StealCycles( cpu.GetClock() );
zxbdragon wrote:
*Spitfire_NES* wrote:
sorry for the double post just wanted to add this real quick. I merged in your fix for burai fighter, but i noticed this overwrites james fix for mickey's in nstppu.cpp he shared a while back.
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
io.line.Toggle( scroll.address & 0x3FFF, cpu.GetCycles() );
}
to
NST_FORCE_INLINE void Ppu::UpdateScrollAddressLine()
{
if (io.line)
{
int a12_mask = ~((scroll.address & 0x2000) >> 1);
io.line.Toggle( (scroll.address & a12_mask) & 0x3FFF, cpu.GetCycles() );
}
}
This part was overwritten so mickeys return back to the shaky status bar. Is there a way to put this back in for both games to coexist peacefully?
Integration code
if (!(regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED) ||
(scanline == SCANLINE_VBLANK)) {
UpdateAddressLine(scroll.address & 0x3fff);
}
to UpdateScrollAddressLine;
I tried your fix zxbdragon to get the mickeys fix reverted back to this:
if ((regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED) && !(data & Regs::CTRL1_BG_SP_ENABLED))
UpdateScrollAddressLine(scroll.address & 0x3fff);
and mickeys did not revert back. What did you do exactly and what is the best way to integrate james fix and your patch?
Thanks again for all your contributions to this. Looks like we are all learning something here lol.
As for ninja gaiden ill add this in and give it a whirl and see where it goes. I dont think anything will get broken in the process as you seem to know your ins and outs far better than me.
@perilsensitive
Please, you must rephrase what you wrote about the IRQ fix. It's quite confusing to me, since you mixed it with tepple's question.
I've been looking into the problem with Safari in Letterland a bit more after briefly discussing the issue with James via PM, and I have data explaining why the shaking happens, as well as a possible theory for what the actual fix is. Of course, it's possible that somebody has already tested this aspect of the MC-ACC and my theory is wrong, but I can't think of a better explanation at the moment. :-/
The status bar shakes due to the IRQ firing early on some frames. It is supposed to fire on scanline 205, but occasionally fires on scanline 204 (James pointed out some $2006 updates that occur when rendering; these happen one scanline after the IRQ). It fires on scanline 204 instead due to an extra clock occurring around cycle 300 on scanline 188. That clock happens because the game disables rendering around cycle 276 (putting vramaddr_v onto the address bus), then writes a palette address to $2006 around cycle 300 (putting the $3Fxx address onto the bus). If the vertical scroll value was even at the time rendering was disabled, this triggers an A12 rise. The difference in PPU clocks between when A12 falls and then rises again is between 24 and 30 clocks, clearly more than 15, so the IRQ counter gets clocked.
The only way around this (assuming that the PPU does put the palette address onto the bus and that nothing else is being emulated incorrectly), is to require more time between A12 rises in order to clock the counter. This doesn't seem unreasonable, especially since we already know that the MC-ACC doesn't *quite* behave like an MMC3. The required time between rises must be
at least the same as required by the MMC3, but there's no reason it couldn't be greater. I tried various values and found that a minimum of 39 PPU cycles (or 13 M2 cycles, since the cart doesn't have access to the PPU clock signal) are required to fix the shaky status bar. The actual required time between rises may be larger than this, but there's no way to know what it is without testing an actual MC-ACC.
I've tested this theory in my emulator as well as Nestopia, and the shakes completely disappear (and the status bar looks correct: no scanline missing from the middle). I don't have a clean patch for Nestopia yet though, and simply changing the value of CLOCK_FILTER in NstBoardMmc3.hpp (as I did to test this theory) will definitely break actual MMC3 games. This is all purely academic if my theory is wrong though, so I'm hesitant to create a patch until this is confirmed (if it is confirmed).
Zepper wrote:
@perilsensitive
Please, you must rephrase what you wrote about the IRQ fix. It's quite confusing to me, since you mixed it with tepple's question.
I will reply via PM to avoid repeating myself in the thread.
hey peril, in the meantime what is the easiest way to merge the 2 patches together until a proper fix is found if you dont mind me asking?
perilsensitive wrote:
zxbdragon wrote:
You find a better solution ?
I don't have a solution yet. Every emulator that implements these extra reads caused by DMA has similar glitches, so *nobody* has a solution yet. You could disable the extra reads altogether, although this would still be a hack. No games depend on this behavior, and many emulators simply don't implement it at all (FCEUX, for example). It is of interest to NES developers though, especially when it causes extra reads of the controller ports.
You could do something like this in NstApu.cpp to disable the reads if the glitch really bothers you that much:
Code:
diff --git a/source/core/NstApu.cpp b/source/core/NstApu.cpp
index cf1f3df..cd14e6c 100644
--- a/source/core/NstApu.cpp
+++ b/source/core/NstApu.cpp
@@ -2137,19 +2137,19 @@ namespace Nes
{
cpu.StealCycles( cpu.GetClock(3) );
}
- else
- {
- NST_DEBUG_MSG("DMA/Read conflict!");
+ // else
+ // {
+ // NST_DEBUG_MSG("DMA/Read conflict!");
- cpu.StealCycles( cpu.GetClock(1) );
+ // cpu.StealCycles( cpu.GetClock(1) );
- if ((readAddress & 0xF000) != 0x4000)
- cpu.Peek( readAddress );
+ // if ((readAddress & 0xF000) != 0x4000)
+ // cpu.Peek( readAddress );
- cpu.StealCycles( cpu.GetClock(1) );
- cpu.Peek( readAddress );
- cpu.StealCycles( cpu.GetClock(1) );
- }
+ // cpu.StealCycles( cpu.GetClock(1) );
+ // cpu.Peek( readAddress );
+ // cpu.StealCycles( cpu.GetClock(1) );
+ // }
dma.buffer = cpu.Peek( dma.address );
cpu.StealCycles( cpu.GetClock() );
thank you,I know how to solve the!
can you list the 2 changes zxbdragon? Im still trying to figure out your implementation code for mickeys. What did you do for ninja gaiden?
Interesting how many issues have been discussed in this thread.
I'm understanding the Ninja Gaiden issue quite a bit better now.
perilsensitive, awesome work. I'm trying to digest all of the stuff you've posted still.
*Spitfire_NES* wrote:
can you list the 2 changes zxbdragon? Im still trying to figure out your implementation code for mickeys. What did you do for ninja gaiden?
perilsensitive ,Delete code
cpu.StealCycles( cpu.GetClock(1) );
if ((readAddress & 0xF000) != 0x4000)
cpu.Peek( readAddress );
cpu.StealCycles( cpu.GetClock(1) );
cpu.Peek( readAddress );
cpu.StealCycles( cpu.GetClock(1) );
zxbdragon wrote:
*Spitfire_NES* wrote:
can you list the 2 changes zxbdragon? Im still trying to figure out your implementation code for mickeys. What did you do for ninja gaiden?
perilsensitive ,Delete code
cpu.StealCycles( cpu.GetClock(1) );
if ((readAddress & 0xF000) != 0x4000)
cpu.Peek( readAddress );
cpu.StealCycles( cpu.GetClock(1) );
cpu.Peek( readAddress );
cpu.StealCycles( cpu.GetClock(1) );
Thank you zxbdragon, is this in Apu.cpp and does deleting this break anything or other games? Please post your mickeys fix integrated code diff when you get a chance. Im currently trying to integrate the burai and mickeys fix for the time being.
This is all you really need to eliminate the Ninja Gaiden (U) moon problem:
Code:
//if ((readAddress & 0xF000) != 0x4000)
// cpu.Peek( readAddress );
I suppose this still qualifies as a hack. At least this way it still passes dma_4016_read.nes.
tehcloud wrote:
This is all you really need to eliminate the Ninja Gaiden (U) moon problem:
Code:
//if ((readAddress & 0xF000) != 0x4000)
// cpu.Peek( readAddress );
I suppose this still qualifies as a hack. At least this way it still passes dma_4016_read.nes.
Good point. I didn't think to try that.
Still has this problem though. Sorry about the white line on the left, that's part of the window border.
tehcloud wrote:
Still has this problem though. Sorry about the white line on the left, that's part of the window border.
The top part of the ninja's face is visibile and shouldn't be. It's made of sprites that are normally hidden due to the 8-sprite limit, and they should only appear if you disable the limit. If this is just in the unix port, it looks like the logic for setting unlimited sprites has been swapped:
Code:
diff --git a/source/unix/video.cpp b/source/unix/video.cpp
index 2b06b36..910cba0 100644
--- a/source/unix/video.cpp
+++ b/source/unix/video.cpp
@@ -374,8 +374,8 @@ void video_set_filter() {
break;
}
- // Set the sprite limit: true = enable sprite limit, false = disable sprite limit
- video.EnableUnlimSprites(conf.video_unlimited_sprites ? false : true);
+ // Set the sprite limit: false = enable sprite limit, true = disable sprite limit
+ video.EnableUnlimSprites(conf.video_unlimited_sprites ? true : false);
// Set Palette options
switch (conf.video_palette_mode) {
EDIT: Clarified my explaination. The black square in the corner isn't the problem; it's the fact that the sprites that make up the top row of the ninja's face shouldn't be visible at all due to the 8-sprite limit.
Thanks for pointing that out. Durrr.
Found the problem with Burai Fighter. Of course, this is a first look.
At $2007 read/write, if rendering is enabled, the PPU updates X and Y scroll bits at same time.
If rendering is disabled, the things are "normal": the PPU address (loopy_v) is incremented by 1 or 32.
The scorebar is fixed.
glad you got it sorted zepper!
I had a question for peril sensitive. After merging in your fix for first pass at Mc-Acc support i get some errors with the mmc3 hpp file.
NstBoardMmc3.hpp(124): error C2248: 'Nes::Core::Timer::A12<void,0,0>::Filter' : cannot access inaccessible class declared in class 'Nes::Core::Timer::A12<void,0,0>'
NstBoardMmc3.hpp(124): error C2512: 'Nes::Core::Timer::A12<Unit,Hold,Delay>' : no appropriate default constructor available
with
[
Unit=Nes::Core::Boards::Mmc3::BaseIrq,
Hold=39,
Delay=0
]
NstBoardMmc3.hpp(124): error C2614: 'Nes::Core::Boards::Mmc3::Irq<Delay,Filter>' : illegal member initialization: 'A12' is not a base or member
with
[
Delay=0,
Filter=39
]
NstBoardMmc3.hpp(124): error C2955: 'Nes::Core::Timer::A12' : use of class template requires template argument list
src\Nestopia\source\core\vssystem\../NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NstBoardMmc3.hpp(124): error C2975: 'Nes::Core::Timer::A12' : invalid template argument for 'Hold', compile-time evaluatable constant expression expected
src\Nestopia\source\core\vssystem\../NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2248: 'Nes::Core::Timer::A12<void,0,0>::Filter' : cannot access inaccessible class declared in class 'Nes::Core::Timer::A12<void,0,0>'
NestopiaX error C2248: 'Nes::Core::Timer::A12<void,0,0>::Filter' : cannot access inaccessible class declared in class 'Nes::Core::Timer::A12<void,0,0>'
NestopiaX error C2248: 'Nes::Core::Timer::A12<void,0,0>::Filter' : cannot access inaccessible class declared in class 'Nes::Core::Timer::A12<void,0,0>'
NestopiaX error C2248: 'Nes::Core::Timer::A12<void,0,0>::Filter' : cannot access inaccessible class declared in class 'Nes::Core::Timer::A12<void,0,0>'
NestopiaX error C2248: 'Nes::Core::Timer::A12<void,0,0>::Filter' : cannot access inaccessible class declared in class 'Nes::Core::Timer::A12<void,0,0>'
NestopiaX error C2512: 'Nes::Core::Timer::A12<Unit,Hold,Delay>' : no appropriate default constructor available
with
[
Unit=Nes::Core::Boards::Mmc3::BaseIrq,
Hold=16,
Delay=0
]
NestopiaX error C2512: 'Nes::Core::Timer::A12<Unit,Hold,Delay>' : no appropriate default constructor available
with
[
Unit=Nes::Core::Boards::Mmc3::BaseIrq,
Hold=16,
Delay=0
]
NestopiaX error C2512: 'Nes::Core::Timer::A12<Unit,Hold,Delay>' : no appropriate default constructor available
with
[
Unit=Nes::Core::Boards::Mmc3::BaseIrq,
Hold=16,
Delay=0
]
NestopiaX error C2512: 'Nes::Core::Timer::A12<Unit,Hold,Delay>' : no appropriate default constructor available
with
[
Unit=Nes::Core::Boards::Mmc3::BaseIrq,
Hold=16,
Delay=0
]
NestopiaX error C2512: 'Nes::Core::Timer::A12<Unit,Hold,Delay>' : no appropriate default constructor available
with
[
Unit=Nes::Core::Boards::Mmc3::BaseIrq,
Hold=16,
Delay=2
]
NestopiaX error C2614: 'Nes::Core::Boards::Mmc3::Irq<>' : illegal member initialization: 'A12' is not a base or member
NestopiaX error C2614: 'Nes::Core::Boards::Mmc3::Irq<>' : illegal member initialization: 'A12' is not a base or member
NestopiaX error C2614: 'Nes::Core::Boards::Mmc3::Irq<>' : illegal member initialization: 'A12' is not a base or member
NestopiaX error C2614: 'Nes::Core::Boards::Mmc3::Irq<>' : illegal member initialization: 'A12' is not a base or member
NestopiaX error C2614: 'Nes::Core::Boards::Mmc3::Irq<Delay>' : illegal member initialization: 'A12' is not a base or member
with
[
Delay=2
]
NestopiaX error C2955: 'Nes::Core::Timer::A12' : use of class template requires template argument list
ore\board\
../NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2955: 'Nes::Core::Timer::A12' : use of class template requires template argument list
/NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2955: 'Nes::Core::Timer::A12' : use of class template requires template argument list
/NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2955: 'Nes::Core::Timer::A12' : use of class template requires template argument list
/NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2955: 'Nes::Core::Timer::A12' : use of class template requires template argument list
/NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2975: 'Nes::Core::Timer::A12' : invalid template argument for 'Hold', compile-time evaluatable constant expression expected
NestopiaX error C2975: 'Nes::Core::Timer::A12' : invalid template argument for 'Hold', compile-time evaluatable constant expression expected
NestopiaX error C2975: 'Nes::Core::Timer::A12' : invalid template argument for 'Hold', compile-time evaluatable constant expression expected
NestopiaX error C2975: 'Nes::Core::Timer::A12' : invalid template argument for 'Hold', compile-time evaluatable constant expression expected
NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
NestopiaX error C2975: 'Nes::Core::Timer::A12' : invalid template argument for 'Hold', compile-time evaluatable constant expression expected
NstTimer.hpp(259) : see declaration of 'Nes::Core::Timer::A12'
i dont know how to use code tags on here, so sorry for the long mess.
i wish there was a way to bring back james updatescrolladdressline code that fixed mickeys rather easily, or an easier way to integrate these 2.
zxbdragon wrote:
???
orginally, james had a fix he sent me to fix burai fighter, it ended up however, fixing mickeys instead. Perilsensitive went on to make a fix for burai fighter, but it ended up overwriting the place where i had james code fix posted.
perilsensitive added a first pass for mcacc support on his github, but it makes my compiler freak out with the errors listed above, all im simply saying is i wonder if theres a way to integrate the 2 using nstppu.cpp for the moment. I cannot get the first pass to compile he has listed up.
*Spitfire_NES* wrote:
zxbdragon wrote:
???
orginally, james had a fix he sent me to fix burai fighter, it ended up however, fixing mickeys instead. Perilsensitive went on to make a fix for burai fighter, but it ended up overwriting the place where i had james code fix posted.
perilsensitive added a first pass for mcacc support on his github, but it makes my compiler freak out with the errors listed above, all im simply saying is i wonder if theres a way to integrate the 2 using nstppu.cpp for the moment. I cannot get the first pass to compile he has listed up.
todo test
https://github.com/dragon2snow/Nestopia ... 2667f18eacI am GPL violator, try to merge, there might be a problem
zxbdragon wrote:
*Spitfire_NES* wrote:
zxbdragon wrote:
???
orginally, james had a fix he sent me to fix burai fighter, it ended up however, fixing mickeys instead. Perilsensitive went on to make a fix for burai fighter, but it ended up overwriting the place where i had james code fix posted.
perilsensitive added a first pass for mcacc support on his github, but it makes my compiler freak out with the errors listed above, all im simply saying is i wonder if theres a way to integrate the 2 using nstppu.cpp for the moment. I cannot get the first pass to compile he has listed up.
todo test
https://github.com/dragon2snow/Nestopia ... 2667f18eacI am GPL violator, try to merge, there might be a problem
thank you zxbdragon. Is this your github? I will test this out and see what happens, what problems do you think there will be?
I was a dumper, Modify nestopia ,Is to verify the DUMP's ROM.
nestopia I can not afford injuries . There are many problems to be solved
Modify fceux
thanks zxbdragon. I was just wondering if this will break other games? Do you know? I added this fix in and see no issues with the 2 games or others, i presume you merged the 2 patches together?
perilsensitive wrote:
The glitch in Ninja Gaiden's intro is caused by
extra $2007 reads due to DPCM DMA. I had this exact same glitch in my emulator, and disabling the extra reads for $2007 "fixed" it. I got the same results in Nestopia with a similar change to Apu::Dmc::DoDMA() in NstApu.cpp. I haven't dug any further into this one yet.
I just want to add that I independently verified that this is the cause of the glitch in Nintendulator. For some strange reason, the game reads a byte from the attribute table ($2007), then resets the PPU address and does ORA $2007. This should be a no-op since it should OR the same value that was read before. If the DPCM read glitch occurs during ORA, the PPU address will be incremented, causing it to OR in a wrong value.
I'm not sure if this bug ever manifests itself on real hardware, I only found one gameplay video from real hardware on YouTube, and the bug didn't show up there. The bug might be masked by the way game does the attribute updates in cutscenes. It first clears the whole attribute table to 0. It then updates the lower nibble for the first 8 bytes. Then it updates the higher nibble for the first 8 bytes. This is then repeated 8 times to cover the full attribute table. Thus it's fairly likely that the glitched read would be 0, or some other benign value, not changing the value when ORed in.
This is conjecture, but the LDA $2007/ORA $2007 wackiness may have been a flawed attempt at fixing the DPCM glitch problem.
The game doesn't do attribute readback ingame (only in cutscenes), so no problems there.
The problem is definitely timing related, since merely enabling Game Genie in Nintendulator (it uses the original Game Genie ROM) is enough to push the timing enough so that the bug doesn't show up.