Page 2 of 3

Re: Why does my MMC1 mapper act like this?

Posted: Fri Jun 20, 2014 12:41 pm
by tepples
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.
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 5:17 am
by ArsonIzer
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 5:45 am
by tepples
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 7:23 am
by ArsonIzer
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:
__ .. ._.
It's mirroring:
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 9:20 am
by tepples
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?

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 2:24 pm
by ArsonIzer
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 3:18 pm
by thefox
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 3:53 pm
by ArsonIzer
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.

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 4:16 pm
by cpow
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. ;)

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jun 21, 2014 8:52 pm
by tepples
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.
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.)

Re: Why does my MMC1 mapper act like this?

Posted: Thu Jun 26, 2014 5:55 pm
by miker00lz
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.

Re: Why does my MMC1 mapper act like this?

Posted: Fri Jan 02, 2015 4:49 pm
by zeroone
@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.

Re: Why does my MMC1 mapper act like this?

Posted: Mon Jan 12, 2015 12:19 pm
by ArsonIzer
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?

Re: Why does my MMC1 mapper act like this?

Posted: Wed Jan 14, 2015 9:46 am
by zeroone
As an experiment, run the CPU much longer in the VBlank period (~75000 CPU cycles).

Re: Why does my MMC1 mapper act like this?

Posted: Sat Jan 17, 2015 3:17 am
by ArsonIzer
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.