It is currently Thu Oct 19, 2017 6:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 38 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Fri Jun 20, 2014 12:41 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
ArsonIzer wrote:
tepples wrote:
Did you get a black screen with beeped Morse code

I have no APU. Do I have to implement sound for this?

That or log the timing and value of writes to $4008, so that you can at least tell when the key makes and breaks. Yet another way is to implement breakpoints in your emulator and then put a breakpoint on the Morse code subroutine to tell what the code is.

Quote:
Is there something else I could do, for instance make a CPU log and check it against another?

At least one version of Nintendulator can make CPU logs. You could make a CPU log in Nintendulator, make another in your emulator, and then write a short program to compare the PC and register values in the two to see where they diverge.

In any case, getting nametable mirroring correct for the MMC1 will help you get mirroring correct for the FME-7 and Action 53 mapper, as they're almost the same mirroring-wise.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 5:17 am 
Offline

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
tepples wrote:
That or log the timing and value of writes to $4008, so that you can at least tell when the key makes and breaks.


I did this. I have no clue how the APU works but I got writes alternating between 0 and 176. This was the output (delay being the amount of ms between each write to 0x4008):

    *beep* data: 176
    delay: 170
    *beep* data: 0
    delay: 48
    *beep* data: 176
    delay: 176
    *beep* data: 0
    delay: 160
    *beep* data: 176
    delay: 64
    *beep* data: 0
    delay: 48
    *beep* data: 176
    ................
    ................

I have yet to compare logs, although I thought this might tell you a bit more about what's wrong.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 5:45 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
As an approximation, >128 means the beeper is being turned on, and 0 means it's being turned off. (The triangle channel is actually far more complicated than that, but this will at least let you render the Morse code error messages.) Try making a graph of on which frames the beeper is on by drawing a pixel as light if it's on or dark if it's off. You should see the dots and dashes of Morse code emerge from that.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 7:23 am 
Offline

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
tepples wrote:
Try making a graph of on which frames the beeper is on by drawing a pixel as light if it's on or dark if it's off. You should see the dots and dashes of Morse code emerge from that.


Holy crap. I didn't make a graph but I simply filled a string with dots and spaces and this ended up being the morse code:

Quote:
__ .. ._.


It's mirroring:

Quote:
MIR The nametable mirroring for this mapper doesn't match any of the
supported mappers. Check PA13-PA10, /PA13, CIRAM A10, and CIRAM
enable, and don't try running the 78.3 test on an emulator that
does not support NES 2.0 format.


That was actually really helpful, I didn't expect it to work. I'll try figuring out what's wrong with the mirroring. Is there any way I can test what's wrong with it, or do I manually have to go line by line through my code? I was stuck on this issue for weeks but I never managed to find anything, not sure if I will now.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 9:20 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
For that, I guess someone might need to write a specific MMC1 test. Do you have a nametable viewer, PPU memory hex viewer, etc. in your emulator?


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 2:24 pm 
Offline

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
tepples wrote:
For that, I guess someone might need to write a specific MMC1 test. Do you have a nametable viewer, PPU memory hex viewer, etc. in your emulator?

No, no and no.

Right now I'm comparing logs (my emu vs nintendulator) with a test called mmc1_a12.nes. I'm not sure what exactly it tests, but it makes my emu crash and it's in cpow's github so I assume I should have at least that working should I want my MMC1 to function decently. If anything new comes up I'll be back. If you have any more suggestions/solutions I'd be glad to hear them.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 3:18 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2962
Location: Tampere, Finland
ArsonIzer wrote:
tepples wrote:
For that, I guess someone might need to write a specific MMC1 test. Do you have a nametable viewer, PPU memory hex viewer, etc. in your emulator?

No, no and no.

It may seem like a waste of time at this point to implement stuff like a nametable viewer, pattern table viewer, hex editor (CPU/PPU memory), etc, but if you did implement them, you would probably end up saving time in the long run.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 3:53 pm 
Offline

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
thefox wrote:
It may seem like a waste of time at this point to implement stuff like a nametable viewer, pattern table viewer, hex editor (CPU/PPU memory), etc, but if you did implement them, you would probably end up saving time in the long run.


It doesn't seem like a waste of time at all. I'm just the kind of guy who has the tendency to use the good ole familiar print line rather than learn how to debug if you know what I mean. I'd like to implement stuff like that, but I get lazy every time I think about it.

I'll try to implement at least a nametable viewer ASAP so I can solve this issue.


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 4:16 pm 
Offline
NESICIDE developer
User avatar

Joined: Mon Oct 13, 2008 7:55 pm
Posts: 1026
Location: Minneapolis, MN
I can't stand when people bash good ol' printf debugging. I *love* that technique and just because I use it before I break out gdb or some other debugging tool does not mean I am a luddite or a Neanderthal. Having said that, I completely agree that developing little "windows into the soul of the machine" you're trying to emulate are incredibly valuable. Just look at how many I've added to NESICIDE. ;)


Top
 Profile  
 
PostPosted: Sat Jun 21, 2014 8:52 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
cpow wrote:
I can't stand when people bash good ol' printf debugging. I *love* that technique

Agreed. I often add a crude form of printf debugging to my NES games, involving two bytes that the program translates to a four-digit hex number and displays every frame. It has saved me from having to jump into FCEUX's step debugger as often.

Quote:
I completely agree that developing little "windows into the soul of the machine" you're trying to emulate are incredibly valuable.

Just make sure that these windows are actually accurate. It's possible to end up making a viewer that incorrectly reflects the machine's state. So make the pattern table and nametable viewer use the same function to read video memory as the renderer. (You'll need to provide a way to read video memory without read side effects so as not to confuse the scanline counter of MMC3 and MMC5, the automatic 4K switching of MMC2 and MMC4, or the use of nametable address bits for high CHR RAM address bits that Oeka Kids and Nanjing mappers do.)


Top
 Profile  
 
PostPosted: Thu Jun 26, 2014 5:55 pm 
Offline
User avatar

Joined: Thu Sep 23, 2010 7:28 pm
Posts: 232
cpow wrote:
The distinction is, I think: it is ignored by the hardware, which doesn't mean you should shift it away.


I'm shifting one bit to the right in MoarNES and all MMC1 games tested look perfect in it.


Top
 Profile  
 
PostPosted: Fri Jan 02, 2015 4:49 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
@ArsonIzer

I ran into exactly the same problem that you are experiencing with MMC1 with my experimental NES emulator. The images generated by my emulator look identical to yours.

I managed to solve the problem doing 2 things: 1) I reversed horizontal and vertical mapping. I currently have no mapper and MMC1 doing the opposite things at least according to the documentation. 2) I discovered that timing greatly affected things. I suggest introducing a longer delay within the vertical blanking period to enable the processor to run more cycles. See if that helps. If more CPU cycles within the vblank solves the problem, then you'll know that you have to improve the timing code.


Top
 Profile  
 
PostPosted: Mon Jan 12, 2015 12:19 pm 
Offline

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
I haven't touched the NES for several months again, so bear with me if I seem forgetful.

zeroone wrote:
@ArsonIzer

I ran into exactly the same problem that you are experiencing with MMC1 with my experimental NES emulator. The images generated by my emulator look identical to yours.

I managed to solve the problem doing 2 things: 1) I reversed horizontal and vertical mapping. I currently have no mapper and MMC1 doing the opposite things at least according to the documentation. 2) I discovered that timing greatly affected things. I suggest introducing a longer delay within the vertical blanking period to enable the processor to run more cycles. See if that helps. If more CPU cycles within the vblank solves the problem, then you'll know that you have to improve the timing code.


Could you elaborate on those points?

1. What do you mean by reversing horizontal and vertical mapping? If you mean that I should set mapping to horizontal when the MMC1 control bit is indicating vertical and vice versa, then no luck. It also seems weird that that would work perfectly.

2. I especially don't get this one. I can't assume that timing is the problem when all tested mapper 0, 2, 3, and 7 games work fine.

For those who are still interested in this error, I found out that there is something wrong with the pattern tables. I looked at FCEUX and my emulator side by side, running the same game, and when the game selects data from the pattern tables, the game running in FCEUX seems to have access to 2 different tables, while mine has access to one (so 0x0000 and 0x1000 are always the same). This means that it's probably either the data being extracted wrong from the ROM, or the mapping always causes the same pattern table to be mapped to the 2 PPU "slots". I hope to figure out quickly which one it is, when I get back to it. If someone has any suggestions until then, that would definitely be appreciated.

EDIT: It seems like I might have 2 separate issues. One is that the pattern tables are accessed wrong SOMEHOW. The other one is that the nametables are wrong. There are games that seem fine-ish and just have peculiar graphic anomalies, while others are completely scrambled. The only MMC1 game that functions fine is Bionic Commando. It has no CHR banks though, maybe that's it. That being said, Mega Man 2 has no CHR banks either and as seen on the first page of this thread, it doesn't work fine at all.

EDIT 2: Bionic commando 2 and Mega Man 2 have no CHR banks yet they (exclusively) use 8K banking. These 2 work, but Mega Man 2 has strange nametable deformities. Addams Family, Adventures in the Magic Kingdom, Darkwing Duck, and Double Dragon have 16 CHR banks, exclusively use 4K banking and all 4 suffer from incorrect pattern tables. What's going on here?


Top
 Profile  
 
PostPosted: Wed Jan 14, 2015 9:46 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 709
Location: New York, NY
As an experiment, run the CPU much longer in the VBlank period (~75000 CPU cycles).


Top
 Profile  
 
PostPosted: Sat Jan 17, 2015 3:17 am 
Offline

Joined: Fri Jul 19, 2013 11:38 am
Posts: 115
zeroone wrote:
As an experiment, run the CPU much longer in the VBlank period (~75000 CPU cycles).


I tried running the PPU only one cycle per CPU cycle while VBlank is active, i.e. the CPU runs 3 times faster/the PPU runs 3 times slower during VBlank. This does not have any effect on any of the games.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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