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.

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.

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.

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.

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.

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.

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.

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.)

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.

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.

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.

Who is online

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