It is currently Fri Nov 24, 2017 1:20 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Apr 18, 2016 7:10 pm 
Offline
User avatar

Joined: Thu May 29, 2014 2:48 pm
Posts: 20
Location: Mexico
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?
Attachment:
Screenshot-O-Nes-Sama-1.png
Screenshot-O-Nes-Sama-1.png [ 11.05 KiB | Viewed 2278 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.
Attachment:
Screenshot-O-Nes-Sama.png
Screenshot-O-Nes-Sama.png [ 8.8 KiB | Viewed 2278 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 ***


Top
 Profile  
 
PostPosted: Tue Apr 19, 2016 4:36 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.


Top
 Profile  
 
PostPosted: Tue Apr 19, 2016 8:52 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
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.


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 10:00 pm 
Offline
User avatar

Joined: Wed Nov 19, 2014 9:00 am
Posts: 40
Location: Mexico
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 ***


Top
 Profile  
 
PostPosted: Wed Apr 27, 2016 9:20 am 
Offline

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


Top
 Profile  
 
PostPosted: Wed Apr 27, 2016 9:56 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
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!


Top
 Profile  
 
PostPosted: Wed Apr 27, 2016 12:22 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
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. ;)


Top
 Profile  
 
PostPosted: Wed Apr 27, 2016 5:45 pm 
Offline
User avatar

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


Top
 Profile  
 
PostPosted: Wed May 04, 2016 5:58 pm 
Offline
User avatar

Joined: Thu May 29, 2014 2:48 pm
Posts: 20
Location: Mexico
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 ***


Top
 Profile  
 
PostPosted: Wed May 04, 2016 7:16 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 1:06 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2981
Location: Tampere, Finland
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: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Thu May 05, 2016 4:56 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Mickey in Letterland also has this behaviour. Sprites must be evaluated/fetched even if sprites are disabled.


Top
 Profile  
 
PostPosted: Thu May 05, 2016 8:55 am 
Offline
User avatar

Joined: Thu May 29, 2014 2:48 pm
Posts: 20
Location: Mexico
@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 ***


Top
 Profile  
 
PostPosted: Fri May 06, 2016 9:35 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
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).


Top
 Profile  
 
PostPosted: Fri May 06, 2016 4:28 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1393
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 11 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group