Rad Racer 2 [MMC3]

infiniteneslives · Post by **infiniteneslives** » Tue May 15, 2012 11:39 am

Ahh I see. I though you fixed the issue and were able to pass blargg's tests. Looks like your timing is still off and failing scanline timing test. We went further into the details on that other thread of yours. Solve those issues ensuring your PPU and CPU are properly in sync. I'm guessing once you get that you'll fix ALL of these IRQ problems.

Zepper · Post by **Zepper** » Thu May 17, 2012 8:54 pm

My emu pass in all MMC3 IRQ tests, including CPU tests.

infiniteneslives · Post by **infiniteneslives** » Thu May 17, 2012 10:02 pm

Oh my bad, I thought I had the latest release.

So if you delay /IRQ's you fix the radracer2 and MM3 issues but then subsequently fail blargg's tests? Interesting...

Near · Post by **Near** » Fri May 18, 2012 1:56 am

infiniteneslives wrote:So if you delay /IRQ's you fix the radracer2 and MM3 issues but then subsequently fail blargg's tests? Interesting...

I kept hitting issues where the exact delay value needed to run MM3 Gemini Stage and Super Mario Bros 3 didn't match what Ryphecha had (5 vs 6 ticks, IIRC), and I'd be surprised if my CPU core still had bad cycle timings. So it certainly makes you feel that there's some incredibly timing-sensitive stuff going on around there.

Zepper · Post by **Zepper** » Fri May 18, 2012 4:11 pm

I'm reviewing my VBlank/NMI timing, as a possible reason for such glitches. Regarding blargg's vbl_timing test (VBlank timing), it says "Reading 1 PPU clock before VBL should suppress setting". Well, should it be done "manually"? In short words, should I put a flag to avoid such thing?

infiniteneslives · Post by **infiniteneslives** » Fri May 18, 2012 7:42 pm

byuu wrote:I kept hitting issues where the exact delay value needed to run MM3 Gemini Stage and Super Mario Bros 3 didn't match what Ryphecha had (5 vs 6 ticks, IIRC), and I'd be surprised if my CPU core still had bad cycle timings. So it certainly makes you feel that there's some incredibly timing-sensitive stuff going on around there.

Not sure if follow, are you saying something like MM3 and SMB3 required different IRQ timings in your emu than someone elses? What are you referring to as ticks? I'm guessing you're talking about number of CPU cycles that CHR A12 must be low before the counter is allowed to be clocked by a subsequent CHR A12 rising edge? If so I'm confused because that would affect which scanline the IRQ would be fired (because you improperly counted scanlines), not what time a IRQ should be fired during a given scanline (specifically what CPU cycle) which is what Zepper is having issues with.

While I agree there are some time sensitive issues with the IRQ, the time that an IRQ should be fired within a given scanline is simple in regards to how the NES works: The CPU must receive the IRQ the exact moment (within logic delays) of the CHR A12 rising edge. This MUST be *mid-cycle* for the CPU (and probably PPU as well), not at the beginning or end of the CPU's current cycle. Now I'm not the guy to ask when it comes to how to do this in an emu, but I have a pretty solid grasp of what's actually happening in the hardware. I would think this means you have to account for what time CHR A12 goes high within the PPU cycle (I'm guessing it's not in the beginning, but sometime mid-PPU cycle I haven't looked at this on my scope but could if desired). Since the PPU and CPU's clocks aren't usually aligned this means that an emulator would have to somehow have keep track of timing and syncronize numerous times within a single PPU/CPU cycle.

I imagine that rounding the time that CHR A12 rises to the beginning of the PPU's cycle could cause issues like Zepper is seeing. If he rounds up to that start of the PPU cycle he passes blargg's tests, and if he delays to the end of the PPU cycle or so, RR2 and MM3 operater properly. My guess is he needs to fire the IRQ in the middle of the PPU cycle to get them both to work. Now I'm making some assumptions on how RockNES might work and might be way off base. But if what I'm saying doesn't make sense let me know, I'll draw a timing diagram to illustrate my point.

Zepper · Post by **Zepper** » Fri May 18, 2012 8:09 pm

@infiniteneslives, let me know if you want to give a look into my sources.

Near · Post by **Near** » Fri May 18, 2012 9:55 pm

> I'm guessing you're talking about number of CPU cycles that CHR A12 must be low before the counter is allowed to be clocked by a subsequent CHR A12 rising edge?

I believe so, yes. Been a few months, emulated a few more systems since then. Basically I am talking about this:

Code: Select all

//this is a thread, tick() adds 12 cycles against a 21MHz clock
void MMC3::main() {
  while(true) {
    if(irq_delay) irq_delay--;
    cpu.set_irq_line(irq_line);
    tick();
  }
}

//called on CHR read and CHR writes
void MMC3::irq_test(unsigned addr) {
  if(!(chr_abus & 0x1000) && (addr & 0x1000)) {
    if(irq_delay == 0) {
      if(irq_counter == 0) {
        irq_counter = irq_latch;
      } else if(--irq_counter == 0) {
        if(irq_enable) irq_line = 1;
      }
    }
    irq_delay = 6;  //Ryphecha uses 5 here, which breaks SMB3 for me
  }
  chr_abus = addr;
}

> which is what Zepper is having issues with.

Sorry, I may have misunderstood. At this point I'm not having an issue, just noting an observation I had when dealing with this chip that I was hoping might be helpful.

> The CPU must receive the IRQ the exact moment (within logic delays) of the CHR A12 rising edge. This MUST be *mid-cycle* for the CPU (and probably PPU as well), not at the beginning or end of the CPU's current cycle.

Oh? I've been trying to get information on this for a while, it seems to be an undocumented area of the NES.

But it's something I needed in SNES emulation very early on: the idea I call bus hold delays. When you read, it puts the address on the bus and waits a set number of clocks. The other chip will see the read and put its data on the bus, at which point it has to be there a bit to stabilize. But the thing is, it's up to the other chip how quickly it will put the data there. The same thing goes for a write, you can put it there on the bus, but it's going to take you some time for the value to stabilize. So the other chip will wait a while there first.

The problem is, how in the world do you know exactly what values to use here? If we assume 12 cycles against the 21MHz clock, do we just wait 6 cycles before doing the read, and 12 cycles for the write? Even then, it likely varies on a per-chip basis, and possibly even on a per-register-per-chip basis.

Also, I'm not even sure I understand the concept of a mid-PPU-cycle. A cycle is usually a point between discrete operations, and in this case we're only doing a single CHR read between each cycle. So you can only really have the return value be at the start or end of the cycle. Having the MMC3 do something in the middle of a PPU read seems like nonsense.

In the middle of a CPU read, sure, that makes more sense because the CPU is doing lots of things in unison: polling IRQ flags, reading from the bus, performing asynchronous DMA (on some systems), etc.

Meh, anyway, we can start a new topic if you'd like to get in depth and feel it'd be off-topic to this discussion. Up to you. FWIW, I already have the means to simulate mid-cycle CPU actions, and I can discuss how I do that if you'd like.

infiniteneslives · Post by **infiniteneslives** » Fri May 18, 2012 11:11 pm

I'll look at em Zepper if you'd like, although my level of understanding your code is going to be heavily dependent on the depth of you comments within the code I'm guessing. email: paul@InfiniteNesLives.com

byuu wrote:Oh? I've been trying to get information on this for a while, it seems to be an undocumented area of the NES.

Kinda, I don't know if blargg understood this exactly or not. But my hardware MMC3 failed when I made this error as did Zepper's emu. We were discussing it and the '5-6 ticks' here That's about the extent of the current documentation to my knowledge.

Also, I'm not even sure I understand the concept of a mid-PPU-cycle. A cycle is usually a point between discrete operations, and in this case we're only doing a single CHR read between each cycle. So you can only really have the return value be at the start or end of the cycle. Having the MMC3 do something in the middle of a PPU read seems like nonsense.

Depending on how your emu works it might be nonsense. But on hardware like you've pointed out signals take time. For instance I think it's safe to say addresses change in the middle of the PPU cycle just like any processor. Clock edge to start cycle then the address becomes valid a few nsec later. The MMC3 doesn't get that valid address (CHR A12 rise) until the PPU is in the midst of it's cycle. It then takes some time for the MMC3 to generate the /IRQ and the CPU to sense that interupt, this is going to be a large delay relatively since it's a pull-up open collector signal. If the time offset between the CPU and PPU clocks is smaller than this entire delay it might be easy to assume that the IRQ arrives at the CPU in the current cycle and will be executed in the next cycle. When in reality this long sequence of events causes the IRQ to delayed to the point where it doesn't arrive at the CPU until the NEXT cycle and will get executed one cycle later. However when the CPU and PPU are aligned I wouldn't expect the delay to be long enough to push the /IRQ into the next CPU cycle.

In any event these delays are present in the hardware and they may be relied upon by certain games. If Zepper gets blargg's tests to pass with no delay and RR2 to work with X delay, then perhaps the sweet spot is between zero and X amount of delay.