G.I. Joe (U) emulation problems

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
aLaix
Posts: 20
Joined: Thu May 29, 2014 2:48 pm
Location: Mexico
Contact:

G.I. Joe (U) emulation problems

Post by aLaix »

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?
Screenshot-O-Nes-Sama-1.png
Screenshot-O-Nes-Sama-1.png (11.05 KiB) Viewed 12657 times
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.
Screenshot-O-Nes-Sama.png
Screenshot-O-Nes-Sama.png (8.8 KiB) Viewed 12657 times

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 ***
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: G.I. Joe (U) emulation problems

Post by Quietust »

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.
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: G.I. Joe (U) emulation problems

Post by Zepper »

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.
User avatar
Fumarumota
Posts: 49
Joined: Wed Nov 19, 2014 9:00 am
Location: Mexico

Re: G.I. Joe (U) emulation problems

Post by Fumarumota »

What's up guys!
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);
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: b) you're handling writes to $2007 in a wrong way.
Checked $2007 and writes behave exactly as in the Skinny of NES Scrolling. I don't see any problems there.
Zepper wrote: Use the MMC3 IRQs test ROMs to be sure about them.
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.

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 ***
x0000
Posts: 43
Joined: Thu Feb 28, 2013 11:14 am
Contact:

Re: G.I. Joe (U) emulation problems

Post by x0000 »

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.
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: G.I. Joe (U) emulation problems

Post by Disch »

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!
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: G.I. Joe (U) emulation problems

Post by Zepper »

Disch wrote:Hard to know how to fix the problem when you don't know what the problem is.
Assuming the graphics engine is "flawless" regarding A12 rises and so on is an error! It puts a tracelog in the shadows. ;)
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: G.I. Joe (U) emulation problems

Post by Disch »

Zepper wrote: Assuming the graphics engine is "flawless" regarding A12 rises and so on is an error!
Well that's the thing. This thread is full of assumptions and a bunch of "guess and check".

- 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.
User avatar
aLaix
Posts: 20
Joined: Thu May 29, 2014 2:48 pm
Location: Mexico
Contact:

Re: G.I. Joe (U) emulation problems

Post by aLaix »

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! :D
*** O-Nes-Sama emulator team ***
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: G.I. Joe (U) emulation problems

Post by koitsu »

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.
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: G.I. Joe (U) emulation problems

Post by thefox »

aLaix wrote:I remember reading that if you disable both OAMs and background
OAM = Object Attribute Memory. It's not a synonym for "sprite".
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: G.I. Joe (U) emulation problems

Post by Zepper »

Mickey in Letterland also has this behaviour. Sprites must be evaluated/fetched even if sprites are disabled.
User avatar
aLaix
Posts: 20
Joined: Thu May 29, 2014 2:48 pm
Location: Mexico
Contact:

Re: G.I. Joe (U) emulation problems

Post by aLaix »

@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!
*** O-Nes-Sama emulator team ***
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: G.I. Joe (U) emulation problems

Post by koitsu »

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?
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).
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: G.I. Joe (U) emulation problems

Post by Quietust »

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.

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).
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).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
Post Reply