Hi all,
Have lurked the boards for a long while and decided to join up today to get in the fun with everyone.
Had a question that maybe more experienced programmers or emudevs might be able to help with.
On young indiana jones chronicles when you get to the end of level 1 a cannonball gets shot onto the ground and makes the screen turn red for a second as if it's a timing issue as well as level 2, the screen starts shaking uncontrollably whenever you move. My question to you guys is this a timing related issue or mapper problem?
BY the way the emus used to test this all prove the same result. Nestopia which is the emu of my choice, jnes, nintendulator and others.
If anyone might be able to help or give insight i would greatly appreciate it. Ive tested this game on the real hardware as well and it is perfect, obviously on the real nes with no glitches like the ones appearing on all the emulators.
Im sorry if i posted this in the wrong place just wanted to get this out here as im trying to figure it out. I'm hoping marty will return to work on nestopia as i have no real coding experience nor do i have knowledge on the innner workings on the nes itself. I am reading into it though so i can try to work on my own projects.
Thanks again and hope to hear from someone who knows what this issue is.
SN-
It's most likely a bad dump.
There's a Polish translation of this game which fixes the faulty V-scroll.
Eightbit Allstar wrote:
It's most likely a bad dump.
There's a Polish translation of this game which fixes the faulty V-scroll.
thanks for the info! ill look into this and see what i can do. i thought it was weird that it played this way on every nes emulator i had tried it on, lol.
I'll make a note to redump my cart soon to verify whether it's a bad dump or incorrect emulation. I tried playing my dump and experienced the same problems you mentioned.
Does the CRC of yours match mine?
http://bootgod.dyndns.org:7777/profile.php?id=699
BootGod wrote:
I'll make a note to redump my cart soon to verify whether it's a bad dump or incorrect emulation. I tried playing my dump and experienced the same problems you mentioned.
Does the CRC of yours match mine?
http://bootgod.dyndns.org:7777/profile.php?id=699
hey bootgod thanks for the answer! yea the crcs match and as well as ive tried 5 diff rom dumps on nestopia all with the same result. EVERY emu does the exact same thing though. jnes, fce, mednafen, nintendulator, they all do. nestopia is the emu of choice though.
interesting enough though, someone on youtube made a v-scroll patch all you have to do is go to youtube and type in "young indiana jones chronicles pl" there is no link for the patch though nor any explanation on how to do it.
hope to hear from you soon and thanks for your input in this thread.
*SpiTfiRe*
Well I redumped it and it matched my previous one. Considering you've tried 5 different copies and all of them experienced the same problem would suggest it's an emulation bug.
Still is a bit surprising, it uses a very common board and I thought the MMC3 was quite well understood.
BootGod wrote:
Still is a bit surprising, it uses a very common board and I thought the MMC3 was quite well understood.
Well, even NROM games can pull tricks that are hard to emulate. I'm really curious to know what the problem is now.
i appreciate your responses bootgod. that dude on youtube i was posting about made some kind of "faulty v-scroll patch" or so he says. i have contacted him and am awaiting further info on exactly what he did.
looks like there might be a couple games left that aren't fully emulated. i know most people prob don't play young Indiana Jones a lot, but i figured someone else would have found this. or maybe they have and dont care, ahaha.
as far as i know nestopia has problems with 2 games, family circuit 91, and this game.
i still am thinking it is perhaps some weird small timing issue on level 1, as far as level 2 goes its almost makes you dizzy the way the screen jerks around and stuff.
looking forward to hearing any updated on this and once again i appreciate all the input.
well i managed to track down the ips patch for this one, still scrolling is ugly and semi-tolerable, apparently this ips patch only disables the vertical scrolling. if anyone is interested in checking this out let me know and ill shoot you a link. the link is only to an ips patch so no roms or what-not.
in the meantime im hoping to find out more about what the issue with this and as always, i appreciate any and everyone's input on this matter.
SN-
with all this talk of mmc3 would timing have alot to do with why this game is so jerky and all? just wondering if anyone knows i know bootgod had posted some info on here.
I just checked on my emu and that game uses MMC3 IRQs. It could be one of the following things that I can think of (if it is in fact an MMC3 problem):
- It could be that none of the emulators you tested are using the appropriate IRQ behavior for MMC3 for that particular game. There are 2 types of behaviors for the IRQ output of MMC3. No one has decided on how to name these 2 behaviors yet so I'll just call them "normal" and "alternate". There is nothing in the game header to tell you which behavior to use. You have to do it by hash/CRC.
- It could actually be something to do with new behavior that we've (Blargg) just (today) discovered in MMC3. Found here:
http://nesdev.com/bbs/viewtopic.php?t=6467 That link also explains the 2 types of IRQ behaviors. Mind you that RevA vs. RevB is _not_ a good name for that post. It should say something more like "normal" vs. "alternate" as I mentioned above.
Although it may not be an MMC3 problem at all. However, I would think that a CPU/PPU core bug would be unlikely especially since _all_ of the emulators you tried did the same thing. I think it's more likely to be an MMC3 mapper bug. But I am _NOT_ a mapper expert.
Unfortunately, I couldn't even get to level 2 to see if the glitching happened on my emu - I keep dying! And I don't have game genie codes implemented yet. Haha.
Okay, so I just tried the game on my emu with both types of IRQ behaviors and neither one fixes the red flashing.
Just FYI, my mapper has the IRQ "fix" that was mentioned above and passes both of Blargg's MMC3 style IRQ tests.
Hmm...it would awesome if someone could figure out what this bug is. If every single emulator out there has the same exact problem, then fixing this bug might lead to a new discovery of the inner workings of the NES, or correct an assumption or conclusion that was incorrectly made it the past. Figuring out what this bug is might also solve some long unsolved riddle of the original hardware. Pretty neat if you think about. And certainly not far-fetched, I mean, come on, _every_ emulator having the same problem???? Wow.
Can the IRQ behavior be determined solely by the MMC3 revision? I'm just wondering if my DB needs to expand on this or if the revision is enough.
interesting stuff and i for one, can't wait to see what the issue is. i appreciate everyone's responses. Im more fascinated with finding out what the issue is more so than the game playing. lol.
maybe it has nothing to do with the mmc3 at all perhaps??
Just found something potentially interesting here. I switched to vertical mirroring mode during the cannonball section of level 1 and while the background was incorrect, the screen shook like it's supposed to.
That is *extremely* odd since the game writes to a mapper register in order to set the appropriate mirroring.....I don't understand that at all!
And you even said you checked the CRC of multiple ROM dumps. Why the heck would the game write the wrong mirroring value?? I mean, obviously it doesn't really since it works in the original NES. But....I know that my H/V mirroring bit in my mapper is correct since it works for so many other games. And obviously, the emus aren't going to have the H/V reversed since it would clearly break many other MMC3 games. What the heck is going on here!?!?
James wrote:
I switched to vertical mirroring mode...
Wait, how did you switch the mirroring mode? You would have to modify the ROM code of the game. How did you know what hex data to change?
here is a link to JUST the ips patch. the scrolling is still GOD-AWFUL on level 2 but now tolerable. Also when the cannonball touches the ground on level 1 near the end it does not turn red.
http://www.detach.republika.pl/IndyVscrollOFF.ips
With this hex you did does that fix stuff? id love to know if you got something working correctly as this patch only turns off the vertical scrolling. enjoy!
jwdonal wrote:
James wrote:
I switched to vertical mirroring mode...
Wait, how did you switch the mirroring mode?
I was running it in FCEUXD and just changed the mirroring mode in the name table viewer.
I think I've found the problem! I'll post more details when I get home from work and have a chance to perform some more tests (the cannon ball section looks good, but I haven't tested level 2, nor have I verified that I haven't broken anything else in the process).
*Spitfire_NES* wrote:
maybe it has nothing to do with the mmc3 at all perhaps??
nothing to do with mmc3
jwdonal wrote:
fixing this bug might lead to a new discovery of the inner workings of the NES, or correct an assumption or conclusion that was incorrectly made it the past
maybe
can't wait to hear it man do let us know when you get a chance!
James wrote:
jwdonal wrote:
James wrote:
I switched to vertical mirroring mode...
Wait, how did you switch the mirroring mode?
I was running it in FCEUXD and just changed the mirroring mode in the name table viewer.
That's awesome. I need to check out FCEUXD sometime soon. I hear lots about it.
I am eager to hear of your discovery as well. Don't let us down now that you have us all psyched up!!
Check out the video -- it looks good to me!
Long story short, incrementing the PPU's vram address by 1 or 32 on $2007 access is only correct when rendering is disabled. The game, however, is reading $2007 mid-screen. It seems that accesses to $2007 during rendering affect the vram address the same way that normal rendering does. In other words, accessing $2007 mid-screen 'clocks' the counters as described in the 'VRAM access during rendering' section of Brad Taylor's 2C02 doc.
Here's my fix. This is called on reads/writes to $2007.
Code:
void c_nes::c_ppu::update_vram_address()
{
if (rendering)
{
if (address_increment == 32)
{
if ((vram_address & 0x7000) == 0x7000)
{
vram_address &= 0x0FFF;
switch (vram_address & 0x03E0)
{
case 0x03A0:
vram_address ^= 0x0800;
case 0x03E0:
vram_address &= 0xFC1F;
break;
default:
vram_address += 0x0020;
}
}
else
vram_address += 0x1000;
}
else
//TODO: this is, more than likely, wrong.
vram_address++;
}
else
vram_address = (vram_address + address_increment) & 0x7FFF;
}
I've put the fix in nemulator 2.1.4, which can be downloaded from
http://nemulator.com, if you'd like to check it out.
edit: fixed a typo in the code
That's interesting. It kind of makes sense in a way.
I wonder if inc-by-1 mode does the same wrapping around the nametable thing.
Like...
Code:
else // inc-by-1
{
if((vram_address & 0x001F) == 0x001F)
vram_address ^= 0x041F;
else
++vram_address;
}
Disch wrote:
I wonder if inc-by-1 mode does the same wrapping around the nametable thing.
That's what I'm thinking as well. I didn't bother with it yet, though, since I don't know how I'd test it.
Is it just me or is this absolutely incredible? James has actually made a new discovery on the inner workings of the NES PPU after all these years and after so many emulators. And the chances of anyone discovering this were almost nil - I'm guessing that young indiana is one of extremely few games (the only game??) that would have this problem. Who knows what other oddities this might fix in various games. And Disch doesn't even have any beef with it - that's pretty much validation of your discovery right there.
Nice work James!!
EDIT: Should James make a new post for this discovery to grab peoples attention? Something other than "young indiana jones..." - more like "New PPU Rendering Discovery" or whatever. Just a thought.
So a read during rendering skips a scanline if inc by 32 or a column if inc by 1. Do I understand right? I wonder what sort of race condition this has with normal rendering.
great work james! im gonna try to get this implemented into nestopia! i cannot for one, thank you enough my man! and it looks great in action too!
i thank everyone for even responding in my thread and can't wait to see what else you guys can do. un-friggin believable!
a round for everyone! lmao
jwdonal wrote:
Nice work James!!
*Spitfire_NES* wrote:
great work james!
Thanks, guys!
tepples wrote:
So a read during rendering skips a scanline if inc by 32 or a column if inc by 1
Yeah, that sounds about right to me, though I haven't tested the latter behavior.
edit: just a little clarification here. Instead of saying 'skips a scanline' I might say that a read during rendering, if address_increment == 32, will point the vram address to the next scanline's data.
It's amazing that this community still makes discoveries like this. Nice work, James.
- Sorry, but if I'm not making any confusion, reading/writing $2005/6/7 is not allowed during rendering, an old info.
Right, but now he's documented the specifics of what happens when you read from $2007 during rendering -- and, better & worse, found a game that uses this 'prohibited' behavior.
lidnariq wrote:
Right, but now he's documented the specifics of what happens when you read from $2007 during rendering -- and, better & worse, found a game that uses this 'prohibited' behavior.
Exactly.
*Amen*
sorry if this a stupid or newb question as obviously i dont have any idea on ppu inner workings but besides the relevant code in this thread is there any way to try this out with like an ips patch or let's say a hex edit of the rom?
just curious and if this comes off as a stupid question i do apologize...
once again excellent work! looks like theres always something new with the nes eh? lol
Well the change presented in this thread is one that would need to be applied to emulators, not to the ROM. So no, there's no way to put it in an IPS patch.
You could probably hack the ROM another way to remove the glitch, but that would be a completely different task.
You know this behavior seems like it'd be relatively easy to test and confirm with a dev cart / Powerpak.
Code:
; assume rendering is disabled
LDA #>SomeAddress
STA $2006
LDA #<SomeAddress
STA $2006
LDA #$18
LDX #$00
STA $2001 ; enable (should probably be timed, see below)
BIT $2007 ; read
STX $2001 ; disable
; confirm how PPU address changed from SomeAddress here
You should probably time this so the write happens between dots 260-320 (when the PPU is unlikely to change the PPU address on its own).
This wouldn't cover possible edge cases when the $2007 read happens at the same time that the PPU is adjusting the address for rendering, but it could at least confirm the basic idea is right.
It is the 2010s and there is time for
Boing 2007. Put this on a PowerPak, put the PowerPak in an NTSC NES, and follow the bouncing ball. As they used to say on alt.aol-sucks: "Your will be amasing."
EDIT: Attached here too
Now the question is "what happens when there is a warp arround" ? Is the circuitry that detects the end of name-table (and warp it to the top/left of the next nametable) is still active when it comes to $2007 reads during rendering ?
When a column is skipped, does the horizontal scroll become back to normal value next line ? (I'm pretty sure so, else Zelda would be f** up when scrolling vertically)
And last, but not least : Is there a way to predict WHAT the $2007 read will return ? A new way of synchronization maybe ?
I wrote a test that runs what Disch suggested and added the output to the Wiki for group analysis:
Reading 2007 during rendering
It sets the VRAM address to 141F before the code, since that seemed to reveal the most operation. If I set it to 0000 for example, you wouldn't see bit 10 getting toggled. the 1F allows that to happen. And the 0400 allows you to see it toggle 1000 sometimes, etc. I'm not up to speed on all the PPU details, so I was mostly just trying values and choosing this one as the most useful.
Yeah, I saw it clock both the H and V positions at some points on the scanline when I was testing boing $2007.
blargg wrote:
And the 0400 allows you to see it toggle 1000 sometimes
Can you explain this? I'm assuming that, in your test, 2000.2 is set (i.e. address increment = 32). In that case, any read of $2007 would clock FV (bits 12-13), toggling 0x1000, no?
Do you think the +1 increment relative to dummy, in most of the reads, is simply a timing difference?
BTW, YIJC doesn't actually do anything with the $2007 read:
Code:
$FB66:8D 00 20 STA $2000
$FB69:AD 02 20 LDA $2002
$FB6C:A5 A7 LDA $00A7
$FB6E:8D 05 20 STA $2005
$FB71:A9 00 LDA #$00
$FB73:8D 05 20 STA $2005
$FB76:A5 A9 LDA $00A9
$FB78:8D 06 20 STA $2006
$FB7B:A5 AA LDA $00AA
$FB7D:8D 06 20 STA $2006
$FB80:A5 A8 LDA $00A8
$FB82:29 04 AND #$04
$FB84:F0 0C BEQ $FB92
$FB86:AD 07 20 LDA $2007
$FB89:AD 07 20 LDA $2007
$FB8C:AD 07 20 LDA $2007
$FB8F:AD 07 20 LDA $2007
$FB92:AC 9F 04 LDY $049F
$FB95:A9 00 LDA #$00
Looks like it's there to simply increment VT by one based on the value of $00A8. Why this couldn't be done before writing to $2005/$2006 is unclear to me.
Sounds like they did the monkeys and typewriters approach - Keep trying something until it works.
I may be off in my analysis... FV is a 3-bit counter, so clocking it 4 times won't necessarily cause a carry into the VT counter.
Maybe they're doing this so that can draw data from 2 halves of different tiles?
Code:
tile 1: tile 2: new tile:
aaaaaaaa xxxxxxxx aaaaaaaa
aaaaaaaa xxxxxxxx aaaaaaaa
aaaaaaaa xxxxxxxx aaaaaaaa
aaaaaaaa xxxxxxxx aaaaaaaa
bbbbbbbb yyyyyyyy xxxxxxxx
bbbbbbbb yyyyyyyy xxxxxxxx
bbbbbbbb yyyyyyyy xxxxxxxx
bbbbbbbb yyyyyyyy xxxxxxxx
?
tepples wrote:
It is the 2010s and there is time for
Boing 2007.
Very cool!
James wrote:
I'm assuming that, in your test, 2000.2 is set (i.e. address increment = 32). In that case, any read of $2007 would clock FV (bits 12-13), toggling 0x1000, no?
No, I had $2000 set to 0, but I just re-ran it with $2000 set to $04 and I get the exact same result. So the increment mode has no effect.
Quote:
Do you think the +1 increment relative to dummy, in most of the reads, is simply a timing difference?
No, since the tests use the same timing for both. I've seen a few entires different from one run to the next, but nothing widespread.
Can you test multiple reads for each increment mode (e.g. 4 reads compared to an appropriate number of NOPs)?
I can test whatever you want. Specify the full conditions: what values do I put in $2000, $2005 and $2006 before the critical code runs?
Same test as before but with 4 LDA $2007 (or 4 LDA $0100 for the dummy reads) instead of 1, with $2000 set to 0 and 4. The existing $2005/$2006 values are fine.
Basically, I just want to see if multiple reads behave as expected or if some other behavior occurs.
(sorry if I introduced some confusion when I mentioned the NOPs. Forgot that you were performing an LDA $0100 to burn an equivalent number of cycles).
Thanks,
James
Sorry for the delay. Quad $2007 read yielded same result regardless of $2000 being 0 or 4. I appended the results to the
Wiki page.
great work on everything guys. its fun to see all this happen and continue! and blaarg you are one friggin smart dude!
sorry for the old bump of this thread. just one quick question for you guys. I want to implement this into nestopia could someone please just let me know where i would need to put this at? would it be in ppu?
i just want to make sure i put it in the right place.
hope someone can help a man out.
**update**
ive tried a couple things but cant seem to figure out where i need to make the change. if someone wouldnt mind helpin a noob out id greatly appreciate it. im still learning about things like this and this could be a sweet learning experience for me.
Didn't Nestopia already fix it in unreleased builds? I thought it did.
Maybe I'm thinking of Nintendulator, which did fix it.
Dwedit wrote:
Didn't Nestopia already fix it in unreleased builds? I thought it did.
Maybe I'm thinking of Nintendulator, which did fix it.
hey dwedit. thanks for the response. nope the only emu to fix it was james on here. the current build of nestopia 1.40 does not have it. it hasnt been updated in years. as far as i know james on here who made the fix has the only emu which is the only one to corretly emulate it.
im trying to use this as learning experience and all so hopefully you or someone could lend a hand or expertise. theres actually a couple things im looking at there seems to be a apu bug in ninja gaiden intro movie where there is a small piece of the moon with a chunk of graphics missing in it.
but i hope someone can come along and lend me a small hand.
Have you tried
Zepper's or
cpow's emulator? I ask because they have been fairly faithful in updating their emus.
*Spitfire_NES* wrote:
as far as i know james on here who made the fix has the only emu which is the only one to corretly emulate it.
Sounds like it's time to switch to nemulator!
ahaha, yea im gonna try it out james no doubt im just trying to get someone to take a minute of their time to lend me a hand and possibly help me out in a learning expperience, i know its prob not that hard to experienced coders but im not quite that good just yet and trying to learn all i can.
i hope someone on here will take a few minutes to even give it a look.....
You'll need to modify the NES_POKE_D(Ppu,2007) function in NstPpu.cpp.
James wrote:
You'll need to modify the NES_POKE_D(Ppu,2007) function in NstPpu.cpp.
thanks james. i really appreciate it man. one more question to you, will this break or affect other games? and what values do i need to change exactly? i been looking over the nestopia source i have and have learned some things, but im not sure what value or what i need to do to the nes_poke_d.
do i just need to change a value of 2007 or some sorts>?
and thanks again man, this community really comes together to help noobs in need like me who are trying to learn what they can.
Sorry, that should've been NES_PEEK_A(Ppu, 2007).
Take a look at that function, then take a look at the code I posted earlier in this thread and see if you can figure it out/spot the similarities. Post your questions here and we'll work through it.
James wrote:
Sorry, that should've been NES_PEEK_A(Ppu, 2007).
Take a look at that function, then take a look at the code I posted earlier in this thread and see if you can figure it out/spot the similarities. Post your questions here and we'll work through it.
ok awesome i like the way this is being done. haha. thanks for even taking your time to do this with me bro. im gonna look at that now.
hey james after looking through the current code the only similarities i see is the 32 and 1 in the nestopias code: scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
and also the code of 07FFF which matches the code fix you made. the rest there are no matches or similiarities that i see, with that said do i need to leave io.latch and the io.buffer alone and modify the code containing the
address = scroll.address & 0x3FFF; part?
perhaps maybe im way off haha.
is it simply a matter of adjusting the line of 0x07FFF and 03FFF to another value? thanks again for taking your time to help with this.
These two statements are equivalent:
vram_address = (vram_address + address_increment) & 0x7FFF;
scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
Notice, however, that my version executes different code when the PPU is rendering:
Code:
if (rendering)
{
//do something that nestopia doesn't do
}
else
{
vram_address = (vram_address + address_increment) & 0x7FFF;
}
So you need to figure out a) how to identify when nestopia's ppu is rendering (i.e., sprites and/or background enabled while on-screen) and b) how to translate my rendering code to nestopia.
vram_address &= 0x0FFF;
switch (vram_address & 0x03E0)
{
case 0x03A0:
vram_address ^= 0x0800;
case 0x03E0:
vram_address &= 0xFC1F;
break;
default:
vram_address += 0x0020;
}
}
else
vram_address += 0x1000;
thats the part of your code thats stumping me. the way im seeing it and prob wrong but it seems like if its rendering at 0x07FFF then i need to switch the address, so what is 0x0800? and oxOFC1F? and also the 0X0020 and 0X1000?
I suspect you're
far from getting the achievement of "the man who fixed nestopia in the world".
Zepper wrote:
I suspect you're
far from getting the achievement of "the man who fixed nestopia in the world".
hahaha i dont want any achievements or credit. i just want to be able to play this on my fave emulator. and any and all credit will go to james for the help or anyone else who is willing to help me learn something new.
i been drivin myself crazy trying to get this done. arrrghhh!
*Spitfire_NES* wrote:
i been drivin myself crazy trying to get this done. arrrghhh!
All your challenge are belong to us
ok -- let's start with some basic questions: 1) what level of C/C++ experience do you have? 2) step 1 is being able to determine when reads occur during rendering -- have you written code for this yet? 3) please post what you've tried already so that we can build off of that/help explain why it hasn't worked yet.
Looks like a copy & paste game.
James wrote:
ok -- let's start with some basic questions: 1) what level of C/C++ experience do you have? 2) step 1 is being able to determine when reads occur during rendering -- have you written code for this yet? 3) please post what you've tried already so that we can build off of that/help explain why it hasn't worked yet.
copy and paste game? lol. what does that mean haha?
im very very low level james. i have tried a couple things and hey im being honest here at least. i tried adjusting some of the parameters of the addresses that you have listed in your fix to nestopia it wasnt much of a change really just a change of the address which obviously isnt right and i learned from that. heres what i have tried:
if scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
{
im stumped here as to what to put
}
else
{
scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0xFC1F;
}
do i know what im doing? hell no? am i trying? hell yes. haha. i still dont understand some of the values in your code like 0xFC1F and the others, do i need to look into another part of the ppu files to find out when it renders? and yea like i said im a noob, but im gonna get it sooner or later.
*Spitfire_NES* wrote:
copy and paste game? lol. what does that mean haha?
Yes, I'm joking
! Thanks for understanding me. ^_^;;
*Spitfire_NES* wrote:
do i know what im doing? hell no? am i trying? hell yes. haha. i still dont understand some of the values in your code like 0xFC1F and the others
I'll superimpose $FC1F on the bit definitions for the current VRAM pointer (loopy_V):
Code:
1111 1100 0001 1111 Decoding the bitmask $FC1F
|||| |||| |||| ||||
|||| |||| |||+-++++- X tile position
|||| ||++-+++------- Y tile position
|||| |+------------- X screen
|||| +-------------- Y screen
|+++---------------- Y pixel position
+------------------- This bit don exits, as far as I know
thanks tepples. so what exactly is that? LOL
AND with $FC1F clears out the Y tile position while preserving the rest of the VRAM address.
tepples wrote:
I'll superimpose $FC1F on the bit definitions for the current VRAM pointer (loopy_V)
Well, I wouldn't say "super", but $7C1F sounds more accurate, even if isn't a major impact after all.
yeah, $7C1F is more accurate.
Hi, guys. I just wanna say hi and thanks for discover a way to fix problem with this game. I've only wrote some kind of emu friendly patch, that helped me fceux and breakpoints, and also was amazed what the reading $2007 is really doing. This threat is interesting, so thanks a lot. Now nice be seeing Nestopia or FCEUX doing the same what nemulator does.
I think that the odd behavior also happens when the big bombs goes off in the first level.
Put this fix into nezulator
im still trying to figure out what to put into nestopia to fix it. blahhh...maybe someone who knows what the heck they are actually doing can post some info haha. :p
Code:
updateVramAddress: function() {
if (this.scanline >= 21 && this.scanline <= 260 && (this.f_bgVisibility || this.f_spVisibility) ) {
if(this.f_addrInc == 1) {
if((this.vramAddress & 0x7000) == 0x7000) {
this.vramAddress &= 0x0FFF;
switch(this.vramAddress & 0x03E0) {
case 0x03A0: this.vramAddress ^= 0x0800; break;
case 0x03E0: this.vramAddress &= 0xFC1F; break;
default: this.vramAddress += 0x20; break;
}
} else {
this.vramAddress += 0x1000;
}
} else {
this.vramAddress += 1; // possibly wrong
}
} else {
// Increment by either 1 or 32, depending on d2 of Control Register 1:
this.vramAddress += (this.f_addrInc==1?32:1);
this.vramAddress &= 0x7FFF;
}
},
this gets called whenever you do a read or write to 2007
Off-topic, any idea where I can get info on the .fm2 and .fcm formats, so I can play back TAS videos in my emu?
I know these are FCEU formats... but I thinka you asking for description.
You can find some info in docs of source code FCEUX. ... here what the first lines of these files contains.
Quote:
FM2 is ascii plain text.
It consists of several key-value pairs followed by an inputlog section.
The inputlog section can be identified by its starting with a | (pipe).
The inputlog section terminates at eof.
Newlines may be \r\n or \n
Quote:
FCE Ultra Save State Format
Updated: Mar 9, 2003
---------------------------------------
FCE Ultra's save state format is now designed to be as forward and backwards
compatible as possible. This is achieved through the (over)use of chunks.
All multiple-byte variables are stored LSB(least significant byte)-first.
Data types:
(u)int8 - (un)signed 8 bit variable(also referred to as "byte")
(u)int16 - (un)signed 16 bit variable
(u)int32 - (un)signed 32 bit variable
-- Main File Header:
The main file header is 16-bytes in length. The first three bytes contain
the string "FCS"...
about Nestopia... source 1.40 just need VC++ 2005 Express, SP1, SDK, and DXSDK to compile, it works - yay. : >
now im trying find out where to put a rule. You thinka should be made maybe in NstCore.cpp, NstPpu.cpp, NstVideoReneder.cpp or somwhere else? Damn.. it looks preety difficult... and where's a docs...
so is that code the fix to put into nestopia? i can compile it just fine. lol. :0
let me know. and thanks!
Zelex wrote:
Off-topic, any idea where I can get info on the .fm2 and .fcm formats, so I can play back TAS videos in my emu?
The docs are in the HTML Help file (.chm) that comes with FCEUX. FCEUX can also convert .fcm -> .fm2.
*Spitfire_NES* wrote:
so is that code the fix to put into nestopia? i can compile it just fine. lol. :0
let me know. and thanks!
Not sure but thinka maybe this method in NstPpu.cpp we should change, but how i'm still wonder.
***Original***
Code:
NES_PEEK_A(Ppu,2007)
{
Update( cycles.one, address );
NST_VERIFY( IsDead() );
address = scroll.address & 0x3FFF;
scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
UpdateScrollAddressLine();
io.latch = (address & 0x3F00) != 0x3F00 ? io.buffer : palette.ram[address & 0x1F] & Coloring();
io.buffer = (address >= 0x2000 ? nmt.FetchName( address ) : chr.FetchPattern( address ));
return io.latch;
}
Now I updated this metod to smth like this and it works fine.
***Modified***
Code:
NES_PEEK_A(Ppu,2007)
{
Update( cycles.one, address );
// NST_VERIFY( IsDead() );
address = scroll.address & 0x3FFF;
//scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
if ((scanline >= 21 && scanline <= 260 ) && (regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED)) {
if (regs.ctrl[0] & Regs::CTRL0_INC32) {
if((scroll.address & 0x7000) == 0x7000) {
scroll.address &= 0x0FFF;
switch(scroll.address & 0x03E0) {
case 0x03A0: scroll.address ^= 0x0800; break;
case 0x03E0: scroll.address &= 0x7C1F; break;
default: scroll.address += 0x20;
}
} else {
scroll.address += 0x1000;
}
} else {
scroll.address ++;
}
} else {
scroll.address = (scroll.address + ((regs.ctrl[0] & Regs::CTRL0_INC32) ? 32 : 1)) & 0x7FFF;
}
UpdateScrollAddressLine();
io.latch = (address & 0x3F00) != 0x3F00 ? io.buffer : palette.ram[address & 0x1F] & Coloring();
io.buffer = (address >= 0x2000 ? nmt.FetchName( address ) : chr.FetchPattern( address ));
return io.latch;
}
I'm used part of assert IsDead() and think f_bgVisibility and f_spVisibility can be replaced by (regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED)) that gave me correct works Battle Toads airship intro. Address increment obvious is (regs.ctrl[0] & Regs::CTRL0_INC32), I think is enough for working Indiana Jones Chronicles and other games.
Update:
- Now Battle Toads it works.
- Ice Climber works (i just needed to rebuild all project)
- GI JOE, Batman Return of The joker works - condition (address increment check added)
Check this out what nestopia now can
http://www.youtube.com/watch?v=fXPGTNZ2EK4
...and here is the new release...
==============================================
Nestopia 1.40.1 beta 1 - unofficial build
Nestopia-1.40.1b(IndyFix)
==============================================
does this affect or impact any other games at all negatively? thanks for posting that.
plasturion wrote:
nice job!
Thanks!
*Spitfire_NES* wrote:
does this affect or impact any other games at all negatively? thanks for posting that.
I think, it shouldn't. I've tried couple of other games, and didn't notice any difference with working or efficient in compare with v1.40, so that should be enough.
This modification is correct while reading $2007, like indiana jones does ( maybe writing somewhere's too, but I see it's useless ). It was said before that reading/writing $2007 during rendering does the same, but officially this method is prohibited and probably never in use except only this one game. Therefore modify writing function - NES_POKE_D(Ppu,2007) is not necessary, additionally is slightly different and looks more difficult to change, so maybe more experienced people for some reason can update it, if they want. I just wanted to see the same good Nestopia with correctly emulate all prior and this game too, so I think this "make-up" looks pretty good.
looks like the nestopia fix screws up the intro to all the camerica games, micro machines...etc....hmmm
Yeah you're right. I've changed first condition and it helped...
Code:
if ((scanline != SCANLINE_VBLANK ) && (regs.ctrl[1] & Regs::CTRL1_BG_SP_ENABLED))
so what now... second release.. damn.. :>
Wow, now even POKE works good... so you think I should put it there?
I isolate the new part to inline function UpdateVramAddress(), and it's called every write/read $2007.
I think it still needs testing.
Nestopia1.40.1 (IndyFix2)
-------------------------
I peeked up last source code FCEUX 2.1.5, and there's (scanline <240) condition, and this condition works too. I don't really know what is the lo, max value of scanline, but now if it works - who cares.
no worries man. its much appreciated what you are doing.
so what does it looks like exactly now? the code as a whole? what did you take out and where did you add the new part?
thanks again man! theres not much left to make nestopia damn near perfect. i only know of 2 other games with weird issues. looking forward to your response man!
I've stayed with this condition - (scanline != SCANLINE_VBLANK ),
all changes is in last link above in "source" directory, between //---------
*Spitfire_NES* wrote:
2 other games with weird issues
Which games?
ninja gaiden 1 has an apu bug i think where a chunk of the moon is missing in the opening cutscene and family circuit 91 has this weird thing where after one lap the graphics become scrambled and garbled and unplayable.
ok got it to compile. seems pretty good, call me crazy but something seems diff or maybe im not used to everything working correctly. hahah
1. Just save your current copies Nstppu.cpp and Nstppu.hpp from source/core
2. put there modified files
3. If in your debugout directory is executable Nestopia.exe - just delete it. or rename.
4. rebuild project. (if you select build it can think there was no changes and probably will links old binaries)
If you tell more what is different i might help more.
I thought that 1.40.2 is to much so i had to renumber this version...
Now they can be recognized from the codename:
IndyFix : before 1.40.1 ; now 1.40.1b (beta1) (changed only relesenotes)
IndyFix2 : before 1.40.2 ; now 1.40.1 (beta2-final) (this was recompiled with 0x7C1F instead of 0xFC1F but it makes any difference, however looks better)
sweet man. thanks again! it works great and plays great and a big thank you for it~~! i been looking into the apu bug in ninja gaiden and the family circuit 91 issue.
but to set the issue straight. this behavior is "prohibited" but a nes game actually uses it anyways? lol so this fix calls for the correct "illegal" behavior when appropriate while not breaking other games.
*Spitfire_NES* wrote:
but to set the issue straight. this behavior is "prohibited" but a nes game actually uses it anyways? lol so this fix calls for the correct "illegal" behavior when appropriate while not breaking other games.
It's not unlike HTML5, which specifies certain document constructions as non-conforming (and not to be used in new documents) but also specifies how to process them for compatibility with existing documents.
*Spitfire_NES* wrote:
sweet man. thanks again! it works great and plays great and a big thank you for it~~! i been looking into the apu bug in ninja gaiden and the family circuit 91 issue.
Yeah.. that would be nice, to makes something better. I'm glad to hear that, but I'm the only copy-paste man. Finding bug without knowing how it works is kinda impossible. I see that v1.37 doesn't have this bugs. Both games working good. If I could only get some source of that version, or better 1.39 if only works as good as 1.37, but I don't see. It's taken down. Maybe there is a little chance to make the core little backward or debug it with this help.
i have managed to track down the source for 1.39, ninja gaiden works great no missing chunk of moon in the sequence and about to test family circuit 91 as well to see if this works too.
I'm not sure if I understand this quirk correctly;
If you read $2007 during rendering while the PPU is set to 32-byte increments, the PPU shifts the scrolling up one?
Was it mentioned somewhere in the thread what happens when the PPU is set to single-byte increments?
*Spitfire_NES* wrote:
i have managed to track down the source for 1.39, ninja gaiden works great no missing chunk of moon in the sequence and about to test family circuit 91 as well to see if this works too.
Diff the mmc1 code. My guess is that something is broken in there.
thanks james!
after an initial cursory inspection of the apu.cpp for both 1.39 and 1.40, there was a good amount of code change and things stamped out or what not.
my guess is i need to compare the changes in nstboardmmc1.cpp. im hoping its a typo is all the problem hehe
on another note, family circuit 91 is still broken in 1.39, but IIRC it did at once work correctly.
I don't think the Ninja Gaiden issue is an APU bug.
No idea on Family Circuit '91. My emulator does better than Nestopia, but it still has problems in-game.
so you think its mmc1 then? would it perhaps be a clock counter bug?
fixed family circuit '91 in nemulator -- bug in the chr rom/ram banking code for mapper 19.
re: ninja gaiden -- I suspect it's a bug in the mapper code because I've seen similar glitches before. Usually a problem with chr bank switching.
*Spitfire_NES* wrote:
on another note, family circuit 91 is still broken in 1.39, but IIRC it did at once work correctly.
With a bit of luck you can find v1.37 binaries too. That version is doing something with rom before is boot, and then it works good. It shows alert - "One or more file header atributes may have incorrect data! They've been internally adjusted for now." I see that there's some changes with v1.38, couse that alert don't shows up, and has the same problem with passed 1 lap as the v1.40. Maybe mapper should be different, or maybe is not only incorrect header issue, i wonder what.
James wrote:
fixed family circuit '91 in nemulator -- bug in the chr rom/ram banking code for mapper 19.
re: ninja gaiden -- I suspect it's a bug in the mapper code because I've seen similar glitches before. Usually a problem with chr bank switching.
hey james where should i look for the bug for family circuit? im guessing mapper19's cpp file> good work man!
@plasturion i can track down the source for 1.37 real fast and post a link.
http://sourceforge.net/projects/nestopi ... p/download heres the link
*Spitfire_NES* wrote:
@plasturion i can track down the source for 1.37 real fast and post a link.
oh yeah, i want to trow an eye on it... yummie thanks man.
im thinking the problem for fmily circiut 91 lies in NstBrd106.cpp im gonna look at mapper 19 as well, interestingly enough its something to do with mapper 106+103 i think. but theyre not listed in the mapper folder?? LOL
hey plasturion what happened to the code changes you had up this morning? LOL
Some time ago I remember Family Circuit 91 coming up in chat with nestopia author. I know this game originally used mapper 19, then was changed to 210 (which was thought to be a slimmed down version of 19 and not completely compatible), but then it was changed back to 19 at some point.
Anyways, I thought this was fixed too, but I just checked and yeah it is busted (again). I'm pretty sure this was working during the period it was assigned to 210. I don't know exactly when that was, probably 1.38 / 1.39
I jumped the gun on declaring Family Circuit '91 fixed. It would run fine, but then after a while, the graphics would get garbled.
The problem coincided with writes to $C000 (mirroring register). If I ignore writes there, it works fine.
So it looks like it may need to be assigned to a different mapper after all.
*Spitfire_NES* wrote:
hey plasturion what happened to the code changes you had up this morning? LOL
I think that assign to mapper 19 is good choice - it's still Namcot 106 board - but it looks like in 1.40 implemented only the soundchip (Namcot 163). So I added swapbanks subroutines there, and fixed part of it with mask addressing. Now i'm going to testing this changes. FC'91 looks fine, but has problem with saving to battery. I noticed It works fine if soundchip is exclude. I think something similar like in 1.37 is needed.
...Now i see that Namcot 106 without it is called Mapper 210, hmm...
Code:
N106::N106(Context& c,const Type type)
:
Mapper (c,PROM_MAX_512K|CROM_MAX_256K|CRAM_8K),
chips (type == TYPE_ADD_ONS ? new Chips(c.cpu,c.apu) : NULL)
{
}
thanks for the update plasturion~! where can this code be added? so if im reading right, the sound chip is disabled, as the game has been moved back to another mapper? but the scrambled graphics should be gone.
I'm still fighting... this code only says that both Namcot 106 (mapper 210) and Namcot 163 (mapper 19) use the same class (in v1.37), but with condiotion (with additional chips or without, that tells second argument of its construcor) Now is support only mapper 19. So I've added modified copy of that to another class to make it compatible with 210 , but nestopia somehow autorecognize mappers and whenever i change to different it shows mapper 19. I don't know where is that part in source and what is checking (CRC or something else).
I'm not sure that is correct mapper anyway... if you like you can broke Namcot163 board getting off the "additional chips" so you can play then FC'97, and games like Mappy Kids, Namco Classics2 will be unplayable. Game is trying to get to "writable page" and than crash, but without additional command Writing is ignored, and works fine.
You can check it yourself commenting one line in NstBrdNamcot163.
Code:
//Map( 0xC000U, 0xC7FFU, &N163::Poke_C000 );
so in a sense we have to break other games to make this one playable? lol. got to be a way to have them all running correctly.
im waiting to see if james has any progress on this as well and see if he gets it fixed.
and keep us updated plasturion.
funny how a simple game as this can cause so much trouble!! lol
It looks simple - i'm testing now added mapper 210, and works great - spliting out compatiblity with 163. But I had to switch off internal database. And only problem is where the adjust database with headers is, to get there changes for this game. And still is chance to change one of the game atribute and make namcot 163 and 106 fully compatible like in 1.37, but It looks that author of Nestopia didn't want it, or didn't done it all.
*Spitfire_NES* wrote:
im waiting to see if james has any progress on this as well and see if he gets it fixed.
It's fixed. If Family Circuit '91 is detected (CRC check), I simply ignore writes to the mirroring registers.
James wrote:
*Spitfire_NES* wrote:
im waiting to see if james has any progress on this as well and see if he gets it fixed.
It's fixed. If Family Circuit '91 is detected (CRC check), I simply ignore writes to the mirroring registers.
sweet sounds like a simple fix to add into nestopia. does this break or affect anything else by chance james?
As it's a CRC check-based fix, behavior is only changed for this specific game. Every other mapper 19 game I checked seems to be working fine.
James wrote:
As it's a CRC check-based fix, behavior is only changed for this specific game. Every other mapper 19 game I checked seems to be working fine.
hmm guess i got to figure out how to disable the crc check for this game and it should be gravy...what do you think mr. plasturion haha.
Looked deep into the email archives and found a couple blurbs about this Namcot stuff from Martin (nestopia author)
Quote:
Yeah, about the Namco 106/163 issue. It looks like I acted too fast. I revisited my code and tested it again and much to my surprise, the games that were supposed to glitch seemed to work just fine on m19 now. I think I may have screwed up somewhere and then later '"fixed" it without knowing it. It's funny though, because FCEU was the emulator that first made this mapper 210 move. I later confirmed the bugs and followed suit. Anyway, I should probably run some more tests, but I think we can safely go back to m19 now and pretend m210 never existed.
Quote:
Following up on the Namco 106/163 issue. I did some more testing and discovered that some of the games never use the nmt-control feature that the mapper provides. Here are the affected games and what mirroring they apparently expect at startup:
Chibi Maruko-Chan - Uki Uki Shopping - vertical
Dream Master - horizontal
Family Circuit '91 - vertical
Famista '92 - vertical
Famista '93 - vertical
Famista '94 - vertical
Heisei Tensai Bakabon - vertical
Top Striker - vertical
Wagyan Land 2 - vertical
Wagyan Land 3 - vertical
All other games initialize mirroring via $Cxxx/$Dxxx on startup. Perhaps there's some board/wiring thing going on here?
IIRC, those games listed all should be hardwired to said mirroring. I know I modified my Namcot copynes plugin to test if mirroring was fixed or software controlled. FC 91 must be writing to $Cxxx, maybe some crap left in from development, but the control line is not connected so it is ignored. The more I think back, I think this was the reason for the switch to 210 (same as 19 but fixed mirroring).
*Spitfire_NES* wrote:
James wrote:
As it's a CRC check-based fix, behavior is only changed for this specific game. Every other mapper 19 game I checked seems to be working fine.
hmm guess i got to figure out how to disable the crc check for this game and it should be gravy...what do you think mr. plasturion haha.
I think you should figure out how to get the crc value into mapper.
In that case the simplest way is modify N163::SubReset inside NstBoardNamcot163.cpp...
Code:
if( gameCrc != 0xC247CC80 ) {
Map( 0xC000U, 0xC7FFU, &N163::Poke_C000 );
Map( 0xC800U, 0xCFFFU, &N163::Poke_C800 );
Map( 0xD000U, 0xD7FFU, &N163::Poke_D000 );
Map( 0xD800U, 0xDFFFU, &N163::Poke_D800 );
}
You have to initialize "gameCrc" and get somehow or calculate game CRC. So I leave the rest to you. Good luck!
so all i need to do is figure out the crc for family circuit 91 then?
No, CRC for FC'91 is C247CC80, you have to figure out how to send or calculate CRC loaded game inside the mapper class N163.
maybe should simply add the same thing as james. if the crc is detected then ignore the writes. is your fix a diff one plasturion?
*Spitfire_NES* wrote:
maybe should simply add the same thing as james. if the crc is detected then ignore the writes. is your fix a diff one plasturion?
That's doing the same, but restriction there don't allow me access to CRC, and comparing outside will make little mess.
I fixed it in another way and same simple, just used internal database and taged this game as with an old board (chip type="106").
plasturion wrote:
*Spitfire_NES* wrote:
maybe should simply add the same thing as james. if the crc is detected then ignore the writes. is your fix a diff one plasturion?
That's doing the same, but restriction there don't allow me access to CRC, and comparing outside will make little mess.
I fixed it in another way and same simple, just used internal database and taged this game as with an old board (chip type="106").
how exactly did you do that? is this is cpp file that needs to be changed for the chip type?
Three things to do:
You need to update a bit NstBoardNamcot163.cpp
Code:
N163::N163(const Context& c)
:
Board (c),
irq (*c.cpu),
sound (*c.apu),
oldBoard (c.chips.Has( L"106" )) //check is it Namcot-106
{
}
declare oldBoard in NstBoardNamcot163.hpp as a bool type.
and this part...
Code:
void N163::SubReset(const bool hard)
{
irq.Reset( hard, hard || irq.Connected() );
if( !oldBoard ) //if isn't Namcot-106 provide nmt-control feature
{
Map( 0x4800U, 0x4FFFU, &N163::Peek_4800, &N163::Poke_4800 );
Map( 0x5000U, 0x57FFU, &N163::Peek_5000, &N163::Poke_5000 );
Map( 0x5800U, 0x5FFFU, &N163::Peek_5800, &N163::Poke_5800 );
Map( 0xC000U, 0xC7FFU, &N163::Poke_C000 );
Map( 0xC800U, 0xCFFFU, &N163::Poke_C800 );
Map( 0xD000U, 0xD7FFU, &N163::Poke_D000 );
Map( 0xD800U, 0xDFFFU, &N163::Poke_D800 );
Map( 0xF800U, 0xFFFFU, &N163::Poke_F800 );
}
erase bottom that definitions that are repeated, and find by CRC inside NstDatabase.xml(zip) FC'91, to change chip type.
are there any other games affected by this change or is it basically that games crc ignored? great work man.
if you have compiled this and confirm it working. can you add the source to your nestopia releases? id love to take a look at the changes you made if you dont mind.
No! Affect is conditioned only by entry in database. Only entry for FC'91 was changed so others must be work as before.
And here is the new release:
Nestopia 1.40.1 IndyFix3
...It would be nice to test it...
So what now... I see that Multicart Contra 100-in-1, Contra 168-in-1. Doesn't work enough good, hmm...
plasturion wrote:
No! Affect is conditioned only by entry in database. Only entry for FC'91 was changed so others must be work as before.
And here is the new release:
Nestopia 1.40.1 IndyFix3 ...It would be nice to test it...
So what now... I see that Multicart Contra 100-in-1, Contra 168-in-1. Doesn't work enough good, hmm...
did those 2 work before? lol.
i dont know if those 2 worked before or not. lol.
ill test those 2 out as well, dont know if they worked before or not. ill give them a go and see if they did before too.
i just tested them both on your new build and they seem to work fine.
Are you sure? I know other games are playable, but Can you play Contra? I can't play this game even on the new FCEUX2.1.5 (for sure works fine with 2.0.0)
what games in question where you having problems playing? looks like you are right. interestingly enough, contra 168in 1 now boots on this new version when it wouldnt on 1.40 haha. but it wont play contra and you are right the other does not play it either.
is this because of the new fixes implemented? thats weird.... i think they are mapper 15 games from what i saw.
Yes they don't, but FCEUX 2.0.0 can, so... Nestopia can't be worse!
Funny it looks like older emulators works better. FCEUX 2.0.3 and Nestopia 1.34 was the last one that play contra on Multicart. I wonder if there was some change inside mapper 15 or somewhere else.
im gonna dig up the source for 1.34 and ill post it up on here for anyone and everyone to look at if they want. im gonna look at it myself.
and here it is....
http://sourceforge.net/projects/nestopi ... p/download
1.34 will only play 100 in 1, for 168 in 1 it says unsupported mapper. haha
hey plasturion did you change something in nsf.cpp? im getting errors saying i cannot modify the 168. it's protected? LOL
What you want modify? Header with mapper, if you did that you have to disable internal database. I think i fixed it, wonna test it ?
yea man if you can send me the files of all the changes id like to see them. and yea send me the build also ill test it. cant wait!
I don't know how much is messed up mapper 15 now but check it if you want...
IndyFix4
I just merged both versions of mapper and somehow it works.. but probably it could be better. Soft reset in 100in1 works awfully like in v1.34.
Code:
ppu.SetMirroring( (data & 0x40) ? Ppu::NMT_H : Ppu::NMT_V );
const uint flip = data >> 7;
data = data << 1 & 0xFE;
switch (address & 0xFFF)
{
case 0x000:
prg.SwapBanks<SIZE_8K,0x0000>( (data+0) ^ flip, (data+1) ^ flip, (data+2) ^ flip, (data+3) ^ flip );
break;
case 0x002:
data |= flip;
prg.SwapBanks<SIZE_8K,0x0000>( data, data, data, data );
break;
case 0x001:
prg.SwapBanks<SIZE_8K,0x0000>( data | (0 ^ flip), data | (1 ^ flip), 0x7E | (0 ^ flip ), 0x7F | (1 ^ flip));
break;
case 0x003:
data |= flip;
prg.SwapBanks<SIZE_8K,0x0000>( data, data+1, data + (~address >> 1 & 1), data+1 );
break;
}
Maybe that code is wrong, but it works. Could someone optimize case 1?
i tried to add the namcot files you changed and im getting errors....it brings up an error in nfs.cpp for some reason. pretty strange, you didnt have any errors compiling that plasturion?
I can compile it just fine.
the error is:
on these 3 lines of code :
if ( n163 ) n163->Reset();
( n163 ? n163->UpdateSettings() : 0U )
(n163 ? n163->GetSample() : 0)
in nstnsf.cpp it says cannot access protected member in class....
Only a subclass can access a class's protected members.
thanks tepples. so whats the best way to correct this to allow access? i dont understand the conflict with the nst cpp file.
That's strange, did you tried to rebuild your project?
If this still occurs try download new source code, copy all needed files, and then open project and compile it.
I did it while ago, and everything seems to be ok.
yea, i got past the error so i started over, now im getting LNK errors for some reason.
its saying the same thing is defined twice. haha. wth.
it says LNK2005 private: unsigned int_fastcall already defined in nstnamcot163.obj
Did you really rebuilded your project? Sounds like linker bug, so everything was compiled successful.
plasturion wrote:
Did you really rebuilded your project? Sounds like linker bug, so everything was compiled successful.
yea i got it to work. thanks alot plasturion ive learned alot from you dude.
. im now looking at the castlevania cross bug when beating Medusa, and the strange glitch in ninja gaiden.
on a side note, anyone know why using some ips patches with nestopia causes mapper errors? when i try to use the english patch for dragon scroll it causes a mapper error but not when i play the unpatched game. its weird..
*Spitfire_NES* wrote:
yea i got it to work. thanks alot plasturion ive learned alot from you dude.
. im now looking at the castlevania cross bug when beating Medusa, and the strange glitch in ninja gaiden.
I'll try throw an eye on this games.
*Spitfire_NES* wrote:
on a side note, anyone know why using some ips patches with nestopia causes mapper errors? when i try to use the english patch for dragon scroll it causes a mapper error but not when i play the unpatched game. its weird..
I think is because of adjust database. Looks like nestopia has pretty low compatibility without it (especially Konami boards - look at NstBoard.cpp case 23). Database use CRC and SHA1 check for identify originally dumped roms, so patched game will be not recognized. There is a way to make patched game works adding new entry in external database, but this is little complicated, and you have to somehow calculate SHA1 with different application.
The best way is using last Nestopia without adjust database(v1.37) for patched roms.
And if we're talking about Nestopia v1.38 and above the best way is create a database with checksums of patched roms unsupported by default. Here is the example how it should looks entry for patched Dragon Scroll ->
xternDatabase.xml
You have to apply .ips patch into rom before you load in Nestopia.
so this needs to be added into the nstdatabase zip file you mean? and the rom needs to be patched with an ips pather before right? or do you mean softpatching. interestingly enough soft patching does work for some konami games in nestopia but not others. lol.
but id love to play dragon scroll translated in here, thanks plasturion. whats the best way to figure out the values to add into the database to play these games? or better yet how did you figure out those values>?
yea if you do look at those other games let me know if you see anything interesting.
*Spitfire_NES* wrote:
castlevania cross bug when beating Medusa
what's the bug?
3. Castlevania - When defeating Medusa (prior to the last boss) sometimes you will receive the cross which destroys all enemies on the screen. Both issues 2 & 3 possible timing related bugs. Both noted here:
http://forums.bannister.org/ubbthreads. ... #Post50410
hey james, about the ninja gaiden thing, shouldnt i be looking in the mmc mapper?
*Spitfire_NES* wrote:
so this needs to be added into the nstdatabase zip file you mean? and the rom needs to be patched with an ips pather before right? or do you mean softpatching. interestingly enough soft patching does work for some konami games in nestopia but not others. lol.
Yes rom needs to be patched before, and some konami games works - for example Esper dream 2 works good, so not every kind of mappers from konami are the same.
If you look at NstBoard.cpp you figure out that there's no support for default mapper 23. (i just changed for a while few lines and do something illegal there - define default type as KONAMI_VRC2, only to make this game load and read the SHA1) You have choice to build entry in internal database or add to external as optional. You can use both databases in the same time. And if you thinking about most popular translation that you like, you probably can put this entries into internal database, extending .exe file a little bit, so i'm not sure this is good idea.
I changed a little bit videofilter what do you think about this?
I allways wants to play mario from end to begining. =>
how did you do that? thats awesome man! let me know...hahah
Or how to play a new levels in a well known old game
I admit the idea is pretty cool.
Although you'd be somewhat familiar with that if you have played Castlevania Symphony of the Night.
*Spitfire_NES* wrote:
what did you change in the filter? which one? blaargs ntsc composite?
i added your entry into nstdatabase.xml and still get unsopported mapper for dragon scroll translation. :O
I just modified NstVideoFilterNone.cpp.
Is
[This] the same patch?
Donwload xternDatabase.xml. Select Options -> Database... add external checkboks and browse selecting this dbase, then open patched Dragon Scroll.
sorry bout that plasturion i got it to work.
haha so if you add this change to the filter all games will be backwards? lol. id love to try it out. but i guess theres no way to make it correct and have it backward right? would have to have 2 exe's? thats still cool. send it my way if you dont mind thats awesome! level flips!
Yeah, thats only videofilter, so all games will be mirror-imaged. I modified only "Standard", others works normal. I often use NTSC - that's was my fav, but now i don't know. I think i could add checkbox to filter options to make mirror-image to be selectable. If you want make some ips-translations list of patches that not working with nestopia (zip them and upload somwhere, i'll try to find CRC and SHA1 to make them be recognized by internal db).
ok man thank! im gonna get on that and send you something soon.
when you can, id like to try out the level flipped stuff you did and see how it is. im interested for sure.
*Spitfire_NES* wrote:
hey james, about the ninja gaiden thing, shouldnt i be looking in the mmc mapper?
just a guess, but that's where I'd look first.
ok thanks james, guess the best thing to do is go back and find the last release to play it right, then go back and compare the 2 files and see what/if anything changed.
i wonder if the ninja gaiden bug would be the same as the medusa/cross bug in castlevania 1. ill keep an eye out for anything new or whatnot plasturion too.
I compared both versions v1.39 and 1.40, and see the changes are only in Cartridge, Apu, Cpu, and Ppu, but mappers seems to be unchanged, and I think it might something to be with added new dendy video mode, and probably we have to look in ppu, but i'm not sure. You can check setting Dendy in Options-> Preferences -> Favored system, and then open ninja gaiden. The big Moon looks as suppose to be.
hmm interesting think maybe a change might be needed in dendy. also hey plasturion did you get my message on here by the way?
I give up, there was many changes in main units... so i'm not interested to fix it. I think sometimes it runs even in Pal, but it hangs rather.
Check Famicom dedicated cart (NTSC) - Ninja Ryukenden (J), the moon looks normal with 60Hz, maybe Ninja Gaiden is indeed dump of Dendy or NES only (PAL) system (or maybe it has some dev-crap with translations), and maybe thats how it should looks like on real hardware as now you can see on 1.40.
Quote:
The graphical error shown in Ninja Gaiden looks like the attribute table isn't getting updated fully. Since the same ROM image works in other emulators, this is probably a timing-related bug (PPU code has a problem, or cycle counting isn't 100% accurate).
Maybe it might be the reason.
Thanks plasturion. Its ok. I appreciate all you have done friend. Let
Me know what other adjustments you make. Im workin on the
list of ips patched games to add to the database.
Quote:
maybe Ninja Gaiden is indeed dump of Dendy or NES only (PAL) system
If it was a dump from a PAL cart it should be named "Shadow Warriors", or at least that's what it should say on the title screen. I don't know what the Dendy version was called, or if there was one.
I'm not sure I understand this Castlevania "bug"...are Medusa heads not supposed to drop crosses? Or does some sort of bug occur after picking up a cross? If it's the former, wouldn't it be a CPU bug (which would certainly break many other games) or a bad/hacked ROM, and not a timing bug? And how could it possibly relate to the discolored moon in Ninja Gaiden?
Is about second boss - queen medusa, while beating her sometimes she drops crucifix, but maybe this item are granted from snakes which she drops too. =] I've played on FCEUX, and she drops blue flacon, and hearts. Probably there's any relation between Castlevania and Ninja Gaiden, but who knows.
-------------------------------------------
Here it is - another release with new videofilter, and some db entries:
IndyFix5
-------------------------------------------
hey plasturion, so you can confirm that there is a difference in what she drops from nestopia to fce ultra? possibly timing, but i find it hard to see too how those both could be related or maybe i'm wrong.
was out of town so didnt get to see many reponses but looks like you made some database entries. great work ill have to check it out.
the only game ive tried yet to work that is ips patched is contra with intro. i guess its the american contra with the japanese scenes added into it.
Yeah, sometimes she drops crucifix in Nestopia1.40, I've played also with v1.39 and there she drops bag of money, and even cross to throw. But maybe there's some randomize item selecting for example at beginning of stage, or is somehow calculated. (I loaded few times to check if she drops other different items but drops the same, but maybe I should start from beginning to confirm this wired rule). Is this bad she's dropping something?
About db entries - i think there's too much with different versions and languages dedicated for one game, most common problem is mapper 23, and most often is using Konami Vrc2 type, I think the best choice is to set default type of mapper 23 to konami vrc2. Send me some titles if you found something new.
hmm interesting. from what i remember you can still beat the level though, i think i used a savestate to make sure i could beat it.
hmmm, im gonna try a couple things and see what happens. im thinking something needs to be either tweaked or backported in to fix these problems, only thing is no one knows where or what the issue is yet. haha.
im still trying older versions of nestopia to see when the problems first arose and when they didnt. alot has already been done to make nestopia even better thanks to you plasturion.
im looking at games to send to you to add into the databse as well.
thanks again for all your hard work!
i poked around and see that free fall prototype is not working correctly. looks like its not because of the changes you made plasturion. seems like its been set to a diff mapper? WTH haha.
I see that Secret Scout (prototype) is not working too. I dig up mapper 11 and removed one line added since 1.38 (mappers rewrite)
Code:
NES_POKE_AD(Ic74x377,8000)
{
ppu.Update();
//data = GetBusData(address,data);
prg.SwapBank<SIZE_32K,0x0000>( data );
chr.SwapBank<SIZE_8K,0x0000>( data >> 4 );
}
I tested all Colordreams (mapper 11) games and everything is now ok.
Maybe this "data = GetBusData(address,data);" is unnecessary, or Martin put it by mistake, but i don't believe that. =]
and here what is doing:
Code:
uint Board::GetBusData(uint address,uint data) const
{
NST_VERIFY( data == prg.Peek(address & 0x7FFF) );
return data & prg.Peek(address & 0x7FFF);
}
The method GetBusData(address,data) appears to simulate the effect of bus conflicts. If this game uses bus-conflict-free ROMs like AOROM does (R/W connected to a positive chip enable) or like ANROM does (/CE = /PRGSEL OR !R/W), the line should not be used. Perhaps the prototype board uses one of these methods of bus conflict avoidance.
is the line to be removed in ppu.cpp? also yea maybe thats the problem with free fall. it used to work in nestopia earlier version but now everything is all scrambled like eggs. hahah
tepples wrote:
The method GetBusData(address,data) appears to simulate the effect of bus conflicts. If this game uses bus-conflict-free ROMs like AOROM does (R/W connected to a positive chip enable) or like ANROM does (/CE = /PRGSEL OR !R/W), the line should not be used. Perhaps the prototype board uses one of these methods of bus conflict avoidance.
Bless thanks for technical explanations tepples. If I right understood, this is some kind of hard assert that has affect on emulation, but doing nothing. So it can be freely removed. right? @*Spitfire_NES* look at NstBoardDiscrete.cpp. I don't imagine nestopia without best ever made game - Free Fall =]
hahaha plasturion so you removed the line:
data = GetBusData(address,data);
from nes_poke_ad and it does not affect the other games?
You can remove or comment this line adding two slash. I tried all games using this mapper (but not beat them) and looks they're ok after that modification. Check
[This] list.
by the way removing this line now makes free fall (prototype) playable
I found a good unofficial release. Would it be possible to integrate the indyfix fixes into this existing source?
http://sites.google.com/site/geestarraw ... pia-1-41-1
changelog:
----------------------------------------------------------------
Unofficial 1.41.1 - by Geestarraw (
geestarraw@gmail.com) (May 17, 2011)
----------------------------------------------------------------
Shell:
Changes:
- Added fullscreen support for non-primary monitor displays.
- Modified Video Options dialog component layout and added device index to
identify mutiple monitors.
- Refactoring.
- Code documentation.
Fixes:
- Fixed so menu is still displayed after fullscreen monitor to monitor switch.
Project:
Changes:
- Converted solution and projects to Visual Studio 2010.
- Improved version enumeration previously locked to x.xx (exactly 3 digits) to
be anything from y.y, y.y.y, and y.y.y.y (where y can be up to 4 digits).
- Changed build output target to nestopia.exe.
Fixes:
- Fixed bug in version enumeration always excluding highest version number.
- Moved unofficial 1.41 release notes to official changelog file.
----------------------------------------------------------------
Unofficial 1.41 - by Keith Kelly (
c0d3h4x0r@hotmail.com) (March 29, 2010)
----------------------------------------------------------------
This is an unofficial maintenance release I created to fix an annoying joystick lag issue.
This lag was particularly bad when VSync was enabled. The original Nestopia author (Martin
Freij) appears to have abandoned the official Nestopia project on SourceForge and has not
responded to any of my e-mails, so I am left with no choice but to provide this unofficial
release as a public service to the emulation community.
Changes:
1. Removed manual option to set priority of Nestopia's main emulation loop thread. Instead,
Nestopia now boosts its own process base priority AND its own main emulation thread priority
whenever it is the active foreground window (and/or running in full-screen mode). This brings
Nestopia much closer to real-time performance and responsiveness.
2. Removed some screwy input polling logic, and added some calls to input.Poll(), to ensure
that the input devices are always polled immediately before the input state is utilized.
This was the key change that got rid of most of the lag.
3. Removed some screwy input timing logic that was causing input polling to work only on
certain clock intervals, rather than allowing it to work every time it was called.
(As far as I can tell on my own hardware configuration, these three changes taken together
have completely eliminated the lag problems that have been present in Nestopia for several
releases. Your mileage may vary.)
4. Updated the Visual Studio solution/project to build successfully under Visual C++ 2008
Express Edition.
5. Added this releasenotes.txt file and bumped the version number to 1.41.
I tested one of release 1.41, 1.41.1 and noticed is little unstable, for example it hangs my computer while Kirby playing on fullscreen, can't know why this could happen (priority process, second thread or something else). In any case maybe this pack of solutions are somehow worth update 1.41, 1.41.1 to IndyFix extension... but i'm not interested. I rather would like to get some stable part of this to enhance 1.40 version.
That and sometimes "screwy input polling logic" such as polling multiple times per frame has its advantages. I've been told that the "BMX Simulator" from Quattro Sports won't work in one build that includes Keith Kelly's patch.
The unofficial update doesn't play nice on my system, either. The frame rate is extremely unstable and tends to freeze a lot (in fact, my entire system becomes unresponsive; I nearly had to reboot because I couldn't exit the program).
Like I've said before, people shouldn't mess around with code they don't fully understand.
is there anything good that has come out of the "unofficial updates"? just out of curiosity.
plasturion wrote:
tepples wrote:
The method GetBusData(address,data) appears to simulate the effect of bus conflicts. If this game uses bus-conflict-free ROMs like AOROM does (R/W connected to a positive chip enable) or like ANROM does (/CE = /PRGSEL OR !R/W), the line should not be used. Perhaps the prototype board uses one of these methods of bus conflict avoidance.
Bless thanks for technical explanations tepples. If I right understood, this is some kind of hard assert that has affect on emulation, but doing nothing. So it can be freely removed. right? @*Spitfire_NES* look at NstBoardDiscrete.cpp. I don't imagine nestopia without best ever made game - Free Fall =]
Most likely explanation is that at development time Color Dreams had a different board, one with protection against bus conflicts, but they removed that to save money. So the real problem (probably) here is that the Secret Scout ROM is marked as iNES mapper 11, when in fact this non-bus-conflicting variant should be given a different number (if it exists, which can be found out by finding a picture of the PCB of the Secret Scout prototype...). Removing the bus conflict handling code from Nestopia is not technically the correct thing to do.
Thanks for that note, I don't know how to know what is the correct mapper number for free fall (prototypes), but I can make some exception using database entry only for this prototypes. So mapper 11 will be with protection against bus conflicts for others colordreams games and without for prototypes. That looks more correct.
plasturion wrote:
Thanks for that note, I don't know how to know what is the correct mapper number for free fall (prototypes), but I can make some exception using database entry only for this prototypes. So mapper 11 will be with protection against bus conflicts for others colordreams games and without for prototypes. That looks more correct.
Nope, that would be vice versa. Mapper 11 is the one with bus conflicts (i.e. doesn't have protection against bus conflicts). We would need to see a picture of the prototype board to see if this hypothesis holds true.
Hi Plasturion,
I have had a few emails with you.
I have been working on updating Nestopia.
I don't agree with adding database entries in the source.
for hacked roms that wont play.
Just get ips win and make an ips file to put in the patch folder,
from original and hacked rom.
Then if you wish, you enable auto-patching,
or load original then ips from launcher.
It will apply to current rom, this is another way of doing it
My latest pre-release Nestopia loads the full set of No-Intro NES.
Of course, I haven't had a chance to play them all through yet.
But they load the first few seconds of intros fine.
2 have graphic glitches, maybe the rom ? more to do.
I added a virtual stereo mod, which really improves the user experience.
Next on list is changing input to RAW so that with 2 monitors,
one can be used to browse etc.
While the other runs Nestopia.
Currently not possible with any known version.
EDIT: only one from the set has graphical issues now, but that also shows on other emus.
So set confirmed
Hi,
oxyandy wrote:
Just get ips win and make an ips file to put in the patch folder,
from original and hacked rom.
Then if you wish, you enable auto-patching,
or load original then ips from launcher.
It will apply to current rom, this is another way of doing it
I think it won't help with several cases. Try to load Dragon Scroll (J) with lasted Nestopia 1.40 or 1.41 (not mine), and then apply ips patch. You'll see an error - unsupported or malfromed mapper. That's because game has new CRC value, and without database entry this game won't run. (the same result will be when you disable internal database and try only open Dragon Scroll).
There are two things to make this better without adding new entries for hacked roms:
- enhance somehow auto-recognizing mapper type (you are able to load Dragon Scroll without database in my last release, but it's almost impossible to make it perfect)
- or force to keep old CRC and SHA-1 (original) value before loading ips patch (that sounds good for me). btw. there's checkbox "bypass CRC validation" - what is doing, is this work?
anyway good to hear all your improvements! I hope your release will be free of mentioned above fatal error - bugs (like in 1.41 that makes system unresponsive on fullscreen, forcing to reboot)
The second best option as I see it is to separate the database of verified good dumps into a separate executable that takes a hash of the PRG and CHR and returns a correct 16-byte iNES or NES 2.0 header. This would allow permanently fixing the header in the ROM file before applying IPS, and it'd allow behavior similar to your "force to keep old": load ROM, get fixed header, load IPS.
The best option would involve a BitTorrent-style
hash list that recognizes inexact matches in order to recognize that a ROM has been partly patched. Again, this would be best as a separate executable so that other tools can make use of it.
Quote:
bugs (like in 1.41 that makes system unresponsive on fullscreen, forcing to reboot)
If somehow through combining source I have introduced this bug, removal is very easy.
How to repeat this bug ?
What makes it happen ?
I just load Dragon Scroll - Yomigaerishi Maryuu (Japan) (No-Intro name)
then the English ips patch and had no problem.
Code:
Dragon Scroll - Yomigaerishi Maryuu (Japan)
Soft-patched: No
CRC: AC9895CC
Soft-patched: Yes
CRC: 24C66CC4
Ok yes I see Official release after loading original then patch doesn't load.
Hmm so an entry is needed in external.xml or if patched rom is really special, the internal one
Is this the same rom ?
I will email you a link
EDIT:
Ok so this is the key to the bug
"full screen (set sync with vblank),"
This will produce an unresponsive system ?
I will confirm shortly, I have needed things open...
I will look over those specific changes later once I finish my work,
thanks
oxyandy wrote:
Ok so this is the key to the bug
"full screen (set sync with vblank),"
This will produce and unresponsive system ?
for 1.41 it was a clue, thanks to you - I could see your pre-release I noticed few more bugs.
I can't see anything on full screen - it's just black screen, after some few alt+enter something wrong with sound sync.
in your release system sometimes goes unresponsive like in 1.41, even sync with vblank is not enable.
I have tried and tried, I can not repeat the bug.
I use 1280 x 1024
View screen size MAX
I normally do not have vsync checked.
but for the testing I have.
I am using standard filter.
Monitor is set primary 1 in video options
Monitor frequency auto.
Colour 16 bit or 32
As input I use Wireless Controllers or the keyboard.
That archive I shared with you had a nestopia.xml included with it.
have you tried deleting that ?
I can easy make a fresh build,
built on top of virgin 140 source
with just the mapper / game fixes,
and this I will do shortly
Quote:
Well I tracked another bug to the flip filter
It causes games to run really fast when displayed on the second monitor.
The smaller the window, the fast it runs.
Also eats up CPU at over 60%
This was confirmed with your own built Nestopia-1.40.1-IF6-unofficial binary.
Flip filter enabled or not.
Will look deeper into the true cause later.
So is not the flip filter, sorry.
I have been busy working,
I did not have a chance to try this with versions prior to 1.40.1-IF6, till now.
I now see this happens with vsync ticked, in 1.40 + 1.36. (I didn't try others)
All I need to do is enable vsync and then drag a windowed Nestopia to the edge of my primary display
so it overlaps slightly onto the secondary display window, then it runs as above, fast.
If the window is small, it runs really fast.
If the window is maximised then it doesn't seem like it is running fast
but, the sound is a bit choppy and breaks up a little.
I wonder if this is similar to the sound problem which so many seem to be plagued with. ?
Quote:
Try to load Dragon Scroll (J) with lasted Nestopia 1.40 or 1.41 (not mine), and then apply ips patch. You'll see an error - unsupported or malfromed mapper. That's because game has new CRC value, and without database entry this game won't run. (the same result will be when you disable internal database and try only open Dragon Scroll).
Ok, I have learnt a lot,
1. To load a patched rom of dragon scroll you need a database entry.
2. To load the ips patch that makes that patched rom you do not need an entry at all.
But, the ips patch needs the same header / mapper info as the original.
So I made this. try this in Official 1.40 and it will load no problem.
http://www.upload.ee/download/1691263/e ... Patched.7z
I traced through the
v-related circuitry in Visual 2C02 to figure out what goes on in this glitch. The short version is that reading or writing $2007 during rendering triggers a Y increment
and a coarse X increment. Here's the explanation:
v is split up into multiple sections (X scroll, Y scroll, horizontal nametable bit, vertical nametable bit, and fine Y scroll), each with a configurable carry in that determines the "next" value for the section. When not rendering, the carries are set up to perform linear increments of
v by either 1 or 32. When rendering, they are set up to perform the operations described in
The skinny on NES scrolling.
The crux is that reading or writing $2007 triggers the "load next value" signal for all the bits of
v (it triggers both of the "load next hscroll value" and "load next vscroll value" signals), and it expects the carries to be set up for a linear increment. During rendering, this instead has the effect of loading both the next Y value and the next coarse X value.
I also updated the "$2007 reads and writes" bullet in The skinny on NES scrolling.
Is the behavior the same, regardless of whether increment is set to 1 or 32?
Drag wrote:
Is the behavior the same, regardless of whether increment is set to 1 or 32?
Yup, the increment setting is ignored while rendering, and that extends to this glitch too.
Unexpected, but important. Good work, Ulfalizer.
Alegend45 wrote:
Unexpected, but important. Good work, Ulfalizer.
Thanks. This does kinda fall in the OCD category though (I only know of one game that cares, and the previously guessed behavior was likely sufficient there), but it's not very hard to get right at least.
BootGod wrote:
Can the IRQ behavior be determined solely by the MMC3 revision?
As far as I can tell, MMC3C and MMC3B S (with S in the same font as the logo of Sharp Electronics) have the new behavior (0 = IRQ every line), and MMC3A and MMC3B (no S) have the old behavior (0 = disable).
Can't remember whether this was mentioned before, but Legend of Zelda does two "inexplicable" $2007 reads in it's vertical scrolling routine (used when screen is scrolling upwards/downwards) at $8566, with rendering enabled. Notably they also didn't know about the $2005/$2006 trick so they only used $2006 when scrolling vertically, making the vertical screen transition slightly choppier than the horizontal one.
Sorry for resurrecting an old thread. But the shaking issue is there on Nintendo's emulator that is used in their games in eShop on 3DS. If you do an inject of this game into that emulator the screen shakes. Unfortunately I cant use another emulator so I need to fix the game itself. I saw that there is an ips patch posted on page 2. is that still the best solution for this?
Duxa wrote:
Sorry for resurrecting an old thread. But the shaking issue is there on Nintendo's emulator that is used in their games in eShop on 3DS. If you do an inject of this game into that emulator the screen shakes. Unfortunately I cant use another emulator so I need to fix the game itself. I saw that there is an ips patch posted on page 2. is that still the best solution for this?
Which part of the game shakes?
zeroone wrote:
Duxa wrote:
Sorry for resurrecting an old thread. But the shaking issue is there on Nintendo's emulator that is used in their games in eShop on 3DS. If you do an inject of this game into that emulator the screen shakes. Unfortunately I cant use another emulator so I need to fix the game itself. I saw that there is an ips patch posted on page 2. is that still the best solution for this?
Which part of the game shakes?
I havent played past the first level but as soon as you start level 1 the whole screen goes up and down constantly. I heard it only gets worse in level 2.
zeroone wrote:
Which part of the game shakes?
Towards the end of the first level, when cannonballs are falling from the sky, and in the second level, when it starts to vertically scroll. Maybe more afterwards, but I've never made it past there.
https://www.youtube.com/watch?v=U4YtfMI1pOY
Yeah look in the video above, see the shake when cannonball hits? Well that shake is there the ENTIRE time.
I tried the IPS patch from page 2; however it did not fix the shake when injected into Nintendo's VC NES emulator.
The fix addressed in this thread is only for the areas shown in the video. There should be no shaking outside of those areas.
James wrote:
The fix addressed in this thread is only for the areas shown in the video. There should be no shaking outside of those areas.
Here is a video of very beginning of the game. Sorry for bad gameplay, had to hold phone in one hand and play with another. You can see that during cutscenes everything is fine, but once level starts there is a shake. This is also the IPS patched version, which I think reduced the shake a tiny bit, I think its even more pronounced without the IPS patch -
https://www.youtube.com/watch?v=yhe3KrjNdc8Found a PC emulator that shows the same problem called NesterJ from 2006. That way you can actually see the bug for yourself. Emulator link -
http://www.emulator-zone.com/doc.php/nes/nesterj.html NesterJ 0.51b English version Windows Freeware Aug 6, 2006 196 Kb.
Here I recorded a video from that emulator so its easier to see -
https://youtu.be/8r6nRy2JW1A?t=14s