G.I. Joe (U) emulation problems
Moderator: Moderators
G.I. Joe (U) emulation problems
Hello guys! It's been a while since my last post!
We have been doing a lot recently in our Emulator, I hope soon we can make a source code release!
Ok, here is the thing, Foomarumota and I have been having trouble emulating this Game called G.I. Joe. At the beginning I thought it was a Mapper problem, but now since we started to debug the game from the PPU, watching the zero hit, and screen splits, and palettes, we don't have a clue of what is happening us!
So I came to the only place I know I can find some help, you guys!
What we are seeing is this:
1. The game crashes after walking a little to the right. We thought it was because of a missed zero hit, but now that we started to look into it, we think that game does not use the zero hit.
Does anybody knows it this is true?
2. At the very end of the screen there is a lot of tiles showing an "S" as the first attachment shows. We have been trying to debug this with FCEUX (i know it's not the best emulator though), and we couldn't find a reason for that tiles to do not show, because FCEUX it's showing them at any scanline we try to debut. And our emulator doesn't trap any loopy_v midframe to hide this tiles, and the background does not turn off too. Instead the background it's turn on twice in a frame, one at scanline 191 and the second time at scanline 248!
Does somebody knows what is the reason that those tiles doesn't show? what is hiding them or turning them off? 3. For some mysterious reason the time counter doesn't move, it stays at 200 but time does indeed run out!
Does anybody has seen this before?
4. The pause screen is wrong too. The same palette is used for all the screen, which for example nintendulator debugger shows that the characters use either palette 1 or 2, and the right part of the screen uses palette 0, but our emulator is using palette 0 for all the screen! And also we noticed that the CHR for the bottom 2 characters are not being switched correct, as seen in the screenshot.
We started to make a debugger for our emulator but it's way in early stages. we will be coding the debugger from now, while we get some help about these issues.
OK I know it's a lot, but i guess if we get some guidance here we will be able to find the root cause of this!
Thank you again Nesdev community for your help! You rock!
We have been doing a lot recently in our Emulator, I hope soon we can make a source code release!
Ok, here is the thing, Foomarumota and I have been having trouble emulating this Game called G.I. Joe. At the beginning I thought it was a Mapper problem, but now since we started to debug the game from the PPU, watching the zero hit, and screen splits, and palettes, we don't have a clue of what is happening us!
So I came to the only place I know I can find some help, you guys!
What we are seeing is this:
1. The game crashes after walking a little to the right. We thought it was because of a missed zero hit, but now that we started to look into it, we think that game does not use the zero hit.
Does anybody knows it this is true?
2. At the very end of the screen there is a lot of tiles showing an "S" as the first attachment shows. We have been trying to debug this with FCEUX (i know it's not the best emulator though), and we couldn't find a reason for that tiles to do not show, because FCEUX it's showing them at any scanline we try to debut. And our emulator doesn't trap any loopy_v midframe to hide this tiles, and the background does not turn off too. Instead the background it's turn on twice in a frame, one at scanline 191 and the second time at scanline 248!
Does somebody knows what is the reason that those tiles doesn't show? what is hiding them or turning them off? 3. For some mysterious reason the time counter doesn't move, it stays at 200 but time does indeed run out!
Does anybody has seen this before?
4. The pause screen is wrong too. The same palette is used for all the screen, which for example nintendulator debugger shows that the characters use either palette 1 or 2, and the right part of the screen uses palette 0, but our emulator is using palette 0 for all the screen! And also we noticed that the CHR for the bottom 2 characters are not being switched correct, as seen in the screenshot.
We started to make a debugger for our emulator but it's way in early stages. we will be coding the debugger from now, while we get some help about these issues.
OK I know it's a lot, but i guess if we get some guidance here we will be able to find the root cause of this!
Thank you again Nesdev community for your help! You rock!
*** O-Nes-Sama emulator team ***
Re: G.I. Joe (U) emulation problems
Have you confirmed that your MMC3 IRQ implementation is behaving correctly?
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: G.I. Joe (U) emulation problems
I'm trying to reproduce your problem with some common errors. No lucky yet. I suspect two things:
a) your MMC3 IRQs are clocking with rendering disabled (means background or sprites enabled, and the scanline is between -1~239);
b) you're handling writes to $2007 in a wrong way.
Use the MMC3 IRQs test ROMs to be sure about them.
a) your MMC3 IRQs are clocking with rendering disabled (means background or sprites enabled, and the scanline is between -1~239);
b) you're handling writes to $2007 in a wrong way.
Use the MMC3 IRQs test ROMs to be sure about them.
- Fumarumota
- Posts: 49
- Joined: Wed Nov 19, 2014 9:00 am
- Location: Mexico
Re: G.I. Joe (U) emulation problems
What's up guys!
I have made some trace logs and IRQ seems to be clocked at the right times; after dot 260 if BG uses $0000 and after dot 332 or so if BG uses $1000 (I only have tested Wolverine for the latter case and works fine).
Maybe it could be some sort of timing or alignment issue between the CPU and PPU... No idea at this point, we'll keep digging.
Any suggestions are welcome.
Thanks a lot for your help!
Our PPU implementation does not make any CHR / NT / Attribute fetches when not rendering, so I guess the A12 rising edge is not clocked in that case (still can be clocked by $2006 / $2007 accesses during VBLANK). I could be wrong though, this can be worth re-checking.Zepper wrote:I'm trying to reproduce your problem with some common errors. No lucky yet. I suspect two things:
a) your MMC3 IRQs are clocking with rendering disabled (means background or sprites enabled, and the scanline is between -1~239);
Checked $2007 and writes behave exactly as in the Skinny of NES Scrolling. I don't see any problems there.Zepper wrote: b) you're handling writes to $2007 in a wrong way.
The weirdest thing is that all test pass, leaving me with few (if any) clues of what's going on. Still Burai Fighter hangs as soon as it begins scrolling, Startropics hangs right after the name registration screen, and G.I. Joe shows as in the screenshots provided by aLaix.Zepper wrote: Use the MMC3 IRQs test ROMs to be sure about them.
I have made some trace logs and IRQ seems to be clocked at the right times; after dot 260 if BG uses $0000 and after dot 332 or so if BG uses $1000 (I only have tested Wolverine for the latter case and works fine).
Maybe it could be some sort of timing or alignment issue between the CPU and PPU... No idea at this point, we'll keep digging.
Any suggestions are welcome.
Thanks a lot for your help!
*** O-Nes-Sama emulator team ***
Re: G.I. Joe (U) emulation problems
To me it looks like scanline counter is clocked too often. Try to run TMNT3 on different levels, see if it has the same issue.
Re: G.I. Joe (U) emulation problems
I always say this... but....
MAKE A TRACELOG
Hard to know how to fix the problem when you don't know what the problem is.
Make a tracelog that dumps an entire frame (vblank to vblank), capturing every instruction that's executed, the state of the IRQ counter at each line, etc, etc. That way you can see exactly what the problem is and can solve it!
MAKE A TRACELOG
Hard to know how to fix the problem when you don't know what the problem is.
Make a tracelog that dumps an entire frame (vblank to vblank), capturing every instruction that's executed, the state of the IRQ counter at each line, etc, etc. That way you can see exactly what the problem is and can solve it!
Re: G.I. Joe (U) emulation problems
Assuming the graphics engine is "flawless" regarding A12 rises and so on is an error! It puts a tracelog in the shadows.Disch wrote:Hard to know how to fix the problem when you don't know what the problem is.
Re: G.I. Joe (U) emulation problems
Well that's the thing. This thread is full of assumptions and a bunch of "guess and check".Zepper wrote: Assuming the graphics engine is "flawless" regarding A12 rises and so on is an error!
- OP posts an image and says "what could be the problem?"
- People make guesses
- He tries them out and says "nope, that wasn't it. What else could it be?"
All of this could be avoided if you make a log so that you can actually see the problem. Then you don't have to guess at what it might be.
If you have a trace log that shows you the emulated instructions, as well as a timestamp (scanline/cycle) and the actual contents of the IRQ counter... you'll be able to see when the IRQ counter is counting down -- and you'll be able to see where it's going wrong, when it's going wrong, and the circumstances that lead to it going wrong.
Then there's nothing to guess about. Because you can actually see it.
Re: G.I. Joe (U) emulation problems
Hello guys, thanks for all your support!
We found what was the cause of all this. I hope this thread would help newcomers to find what is wrong with their emulators!
The OAMs fetches were not working when the OAMs were disabled. So we didn't see it when running other games, and tests would pass, and games like punch out or MMC4 games would work OK, but for this game, it disables the OAMs at scanline 191 and then the MMC3 would stop counting scanlines. So it was a PPU fault!
I remember reading that if you disable both OAMs and background, fetches would stop working and they wouldnt stop when only one was disabled. But now I have a doubt I think I know the answer however I'm not sure. If I disable the OAMs how they become transparent? Is it the sprite evaluation that set FF to each OAM? or when rendering it will output transparent color when OAM is disabled?
Thank you Quietust, Zepper, x0000, Disch for your ideas and comments, they really helped us to find the root cause of this!
Also, we are still working in our Debugger unit for the emulator so we can get way better information about everything. I hope we will surprise you all one day soon!
We found what was the cause of all this. I hope this thread would help newcomers to find what is wrong with their emulators!
The OAMs fetches were not working when the OAMs were disabled. So we didn't see it when running other games, and tests would pass, and games like punch out or MMC4 games would work OK, but for this game, it disables the OAMs at scanline 191 and then the MMC3 would stop counting scanlines. So it was a PPU fault!
I remember reading that if you disable both OAMs and background, fetches would stop working and they wouldnt stop when only one was disabled. But now I have a doubt I think I know the answer however I'm not sure. If I disable the OAMs how they become transparent? Is it the sprite evaluation that set FF to each OAM? or when rendering it will output transparent color when OAM is disabled?
Thank you Quietust, Zepper, x0000, Disch for your ideas and comments, they really helped us to find the root cause of this!
Also, we are still working in our Debugger unit for the emulator so we can get way better information about everything. I hope we will surprise you all one day soon!
*** O-Nes-Sama emulator team ***
Re: G.I. Joe (U) emulation problems
Re: 3rd paragraph questions: seems relevant:
http://wiki.nesdev.com/w/index.php/PPU_ ... _operation -- see last paragraph of section "Internal operation"
http://wiki.nesdev.com/w/index.php/PPU_ ... evaluation -- whole thing, quite honestly
...unless I'm misunderstanding the question?
P.S. -- We (the "royal we") should probably edit the PPU sprite evaluation page to include G.I. Joe as a reference game for "interesting behaviour". Might also be worth adding it to the Tricky-to-emulate games page too.
http://wiki.nesdev.com/w/index.php/PPU_ ... _operation -- see last paragraph of section "Internal operation"
http://wiki.nesdev.com/w/index.php/PPU_ ... evaluation -- whole thing, quite honestly
...unless I'm misunderstanding the question?
P.S. -- We (the "royal we") should probably edit the PPU sprite evaluation page to include G.I. Joe as a reference game for "interesting behaviour". Might also be worth adding it to the Tricky-to-emulate games page too.
Re: G.I. Joe (U) emulation problems
OAM = Object Attribute Memory. It's not a synonym for "sprite".aLaix wrote:I remember reading that if you disable both OAMs and background
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Re: G.I. Joe (U) emulation problems
Mickey in Letterland also has this behaviour. Sprites must be evaluated/fetched even if sprites are disabled.
Re: G.I. Joe (U) emulation problems
@koitsu I read both wiki articles and i couldn't find an explicit mention to the $2001 or disabling/enabling/checking "show sprites". So according to what I understood is that, at the beginning the sprite evaluation set everything to $FF and then when "Sprites found to be within range" happens that checks also if show sprites is enabled, so if show sprites is disabled it wont copy them and then everything will remain $FF. Were my guesses correct?
BTW I added it to http://wiki.nesdev.com/w/index.php/Tric ... late_games, let me know if wording is OK!
BTW I added it to http://wiki.nesdev.com/w/index.php/Tric ... late_games, let me know if wording is OK!
*** O-Nes-Sama emulator team ***
Re: G.I. Joe (U) emulation problems
I'm sorry but I don't have an answer to your question. My impression was that $2001's ability to disable display of sprites correlated with item 2 of PPU sprite evaluation, specifically "On even cycles, data is written to secondary OAM (unless writes are inhibited, in which case it will read the value in secondary OAM instead)". But I'm probably wrong (and happy to be so).aLaix wrote:@koitsu I read both wiki articles and i couldn't find an explicit mention to the $2001 or disabling/enabling/checking "show sprites". So according to what I understood is that, at the beginning the sprite evaluation set everything to $FF and then when "Sprites found to be within range" happens that checks also if show sprites is enabled, so if show sprites is disabled it wont copy them and then everything will remain $FF. Were my guesses correct?
Re: G.I. Joe (U) emulation problems
It is my understanding (which should be fairly easy to test in Visual 2C02) that the enable for sprite evaluation and fetching is exactly the same as that for background fetching: having either enable flag in $2001 set - the only place where the flags are checked individually is in the render pipeline.
That's a totally different thing - the "write inhibit" is what happens after the secondary OAM address overflows (i.e. once 8 sprites are discovered, in step 2c).koitsu wrote:My impression was that $2001's ability to disable display of sprites correlated with item 2 of PPU sprite evaluation, specifically "On even cycles, data is written to secondary OAM (unless writes are inhibited, in which case it will read the value in secondary OAM instead)". But I'm probably wrong (and happy to be so).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.