It is currently Tue Feb 19, 2019 4:33 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 334 posts ]  Go to page Previous  1 ... 18, 19, 20, 21, 22, 23  Next
Author Message
PostPosted: Wed Jan 30, 2019 10:22 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
NewRisingSun wrote:
Ben Boldt wrote:
I am not here to fight with you
Neither am I; I was looking for an explanation and did not get one.

I have added my emulator-tested description to the wiki article while keeping the state diagrams as a "formal description". I only revised my pseudo-code in one way, by setting lastAddress to "undefined" when inFrame becomes false, which turned out to be necessary, otherwise inFrame would be set too early if the address at the end of the frame happened to be the same at the beginning of the next frame because the game never accessed 2006/2007 in its NMI handler. Feel free to revise my description on the wiki once you have done your simulations and discovered any edge cases that are not sufficiently covered.

That sounds great! thanks. Hopefully I can use your description to keep me on the right path as I try things. We know it works exactly or at least almost exactly the way you have understood and documented. That will be very useful for me. I aim to prove or disprove any connection between the status bit and scanline counter/IRQ. They definitely seem to interact but maybe not the the extent I had imagined.


Top
 Profile  
 
PostPosted: Thu Jan 31, 2019 4:48 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
I updated the 'in frame' status bit diagram with your feedback NewRisingSun.

For my own understanding (this is probably old news to you guys), I took some scope shots of PPU /RD in relation to M2. This definitely is different than I was thinking. There are 3 PPU /RD edges for every 2 M2 edges. That's pretty cool. Will try applying my MMC5 signal observations to this.

Attachment:
File comment: 3 PPU /RD edges per 2 M2 edges, also you can see v-blank areas in /RD in the overview.
tek00061.png
tek00061.png [ 31.92 KiB | Viewed 1082 times ]

Attachment:
File comment: Idle cycle
tek00062.png
tek00062.png [ 30.37 KiB | Viewed 1082 times ]

Attachment:
File comment: Scope search function, pointing out all of the idle cycles
tek00063.png
tek00063.png [ 51.37 KiB | Viewed 1082 times ]


Edit:
I didn't look when I was using the scope but my calculations indicate that M2 and the PPU Idle cycle do not coincide in phase. In other words, the PPU Idle cycle will coincide with M2 Low (pictured), the first half of M2 high, or the last half of M2 high. So it cycles through the 3 phases each 3 scanlines. Not sure if that is important or not but it makes more sense why this state machine is so complicated. Will verify it with my scope tomorrow. For me, this stuff is the fun part.

Edit 2:
Confirmed that there is no way that the in-frame bit is setting and clearing for each scanline. That was 100% totally wrong, I screwed up. From what I am seeing now, my theory is that the scanline counter increments each time the bottom state machine becomes unlocked (which happens each scanline, only on PPU cycle 2), and the scanline counter resets each time that the top state machine becomes not-in-frame, which happens on scanline 240, cycle 6, 7, or 8, depending on M2/RD phase. Since there are 262 scanlines, which is not a multiple of 3, I do not believe that the M2/RD phase is the same from one frame to the next for scanline 240 (or any other particular scanline). Will need to verify these things.

Edit 3:
lidnariq wrote:
We've known the horizontal timing for more than a decade: viewtopic.php?p=12379#p12379
Drag wrote a test that took advantage of predictable peculiarities of the PPU's fetch sequence to clock the MMC5 IRQ an extra scanline: viewtopic.php?f=9&t=7653
I am going to hold off reading up on this stuff lidnariq and try to follow through to my own unbiased solutions first, then go back and compare to what you guys did over a decade ago. Hopefully there are differences! That would be exciting.


Top
 Profile  
 
PostPosted: Fri Feb 01, 2019 12:34 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
I was not completely right with the M2/RD phase, it acts in a way I don't quite understand yet when I look at the initial idle cycle of the pre-render frame in 3 sequential frames. In the 3 that I looked at, it had 2 different phases. Hmmmmmmmm... That would seem to suggest that not all frames are the exact same number of PPU cycles. I need to think about it more.

This stuff might not mean much but it has value to close the loop in my understanding so I can proceed correctly with MMC5 interacting with this.

Pictured is the idle cycle of the pre-render scanline for 3 sequential frames. I expected 1 of them to coincide with M2 low and it did not.

Attachment:
phase1.png
phase1.png [ 43.25 KiB | Viewed 1039 times ]

Attachment:
phase2.png
phase2.png [ 43.32 KiB | Viewed 1039 times ]

Attachment:
pahse3.png
pahse3.png [ 42.79 KiB | Viewed 1039 times ]


Top
 Profile  
 
PostPosted: Fri Feb 01, 2019 1:09 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
Ben Boldt wrote:
I was not completely right with the M2/RD phase, it acts in a way I don't quite understand yet when I look at the initial idle cycle of the pre-render frame in 3 sequential frames. In the 3 that I looked at, it had 2 different phases. Hmmmmmmmm... That would seem to suggest that not all frames are the exact same number of PPU cycles. I need to think about it more.
Correct. We know the following two things:

1- The CPU and PPU use independent clock dividers, so the 2C02+2A03 have one of four different alignments randomly depending on power-up state
2- The 2C02 skips one pixel every other vblank when rendering is enabled. This makes the average frame length not 341*262 = 89342 pixels ( = 29780⅔ CPU cycles), but 89341.5 pixels (29780½ CPU cycles)


Top
 Profile  
 
PostPosted: Fri Feb 01, 2019 2:34 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
lidnariq wrote:
Ben Boldt wrote:
I was not completely right with the M2/RD phase, it acts in a way I don't quite understand yet when I look at the initial idle cycle of the pre-render frame in 3 sequential frames. In the 3 that I looked at, it had 2 different phases. Hmmmmmmmm... That would seem to suggest that not all frames are the exact same number of PPU cycles. I need to think about it more.
Correct. We know the following two things:

1- The CPU and PPU use independent clock dividers, so the 2C02+2A03 have one of four different alignments randomly depending on power-up state
2- The 2C02 skips one pixel every other vblank when rendering is enabled. This makes the average frame length not 341*262 = 89342 pixels ( = 29780⅔ CPU cycles), but 89341.5 pixels (29780½ CPU cycles)

Fascinating, do we know the purpose why it skips a cycle ever other v-blank like that?


Top
 Profile  
 
PostPosted: Fri Feb 01, 2019 2:43 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
To get a more desirable dot crawl pattern (cross-luma artifacts in composite video).


Top
 Profile  
 
PostPosted: Fri Feb 01, 2019 4:33 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
NewRisingSun wrote:
To get a more desirable dot crawl pattern (cross-luma artifacts in composite video).

Wow, I never cease to be amazed by this thing.


Top
 Profile  
 
PostPosted: Tue Feb 05, 2019 4:38 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
I wrote a test tonight that I expected to trigger the scanline IRQ on scanline #4. Interestingly, /IRQ stays always high for this test. Note that I tied all PPU address lines to GND and toggled PPU /A13 to select between PPU address $0000 and $2000. I verified that I have no M2 gaps larger than 10 usec.

Here is what this test does in english (numbers corresponding to the code below):
1. CPU Read from address $0000 11 times: 11 M2 toggles with PPU /RD = 1, to make it think not-in-frame
2. CPU Write $18 to $2001: Let the MMC5 sniff the PPU rendering being enabled, not likely necessary

10. CPU Read from $5204: Acknowledge any pending scanline IRQ
11. CPU write $04 to $5203: Set it to have an IRQ on scanline #4.
12. CPU write $80 to $5204: Enable the scanline IRQ.

20. While reading from PPU address $2000, read from CPU address $0000. (PPU read in range)
21. Repeat #20.
22. Repeat #20. 3 consecutive reads from PPU address $2000 have now occurred.
23. While reading from PPU address $0000, read from CPU address $0000. (PPU read out of range)

Loop back to step 20 300 times.
After 300 times, loop all the back to step 1.

I never get any /IRQ from this. Do you guys have any ideas what I should try? Unless I goofed up somewhere, it seems that this is not enough to trick the MMC5 to detect a scanline.

Code:
void writeOnCpuBus( uint16_t address, uint8_t data )
{
    fast_m2_update( 0 );  // Set M2 low.
    // Write CPU address bus:
    OUTP_CPU_ADDRESS_BUS = (address ^ 0x7FFF);
    // Write CPU data bus:
    OUTP_CPU_DATA_BUS = data;
    CPU_RW_PIN = 0;  // MMC5 data bus as input
    MACRO_SET_CPU_DATA_BUS_OUTPUT();  // Pic data bus as Output
    asm(" repeat #12 \n\t nop ");  // Setup Delay, so address and data busses are stable for MMC5 to register the write on M2 falling edge
    fast_m2_update( 1 );  // M2 rising edge.
    asm(" repeat #12 \n\t nop ");  // Setup Delay, This delay improves expansion RAM writes big-time, not sure why.
    fast_m2_update( 0 );  // M2 falling edge.
}

uint8_t readOnCpuBus( uint16_t address )
{
    uint8_t result;
   
    fast_m2_update( 0 );
    MACRO_SET_CPU_DATA_BUS_INPUT();  // Pic data bus as Input
    CPU_RW_PIN = 1;  // MMC5 data bus as output
    // Write CPU address bus:
    OUTP_CPU_ADDRESS_BUS = (address ^ 0x7FFF);
    asm(" repeat #12 \n\t nop ");  // Setup Delay, so address bus is stable for MMC5 to register the read on M2 rising edge
    fast_m2_update( 1 );  // Rising edge M2
    asm(" repeat #12 \n\t nop ");  // Setup Delay, for MMC5 to have data updated and stable on CPU address bus before reading it
    result = (uint8_t)INP_CPU_DATA_BUS;  // Capture CPU data bus
    fast_m2_update( 0 );  // M2 falling edge.
   
    return result;
}

void __attribute__((interrupt, no_auto_psv)) _T1Interrupt( void )
{
    static uint16_t test_state = 0;
    static uint16_t loop_count = 0;
    static uint16_t lock = 0;
   
    switch( test_state )
    {
        case 0:  // Init
            PPU_RD_PIN = 1;
            loop_count = 0;
            test_state++;
            break;
        case 1:
            if( loop_count < 10 )
            {
                readOnCpuBus(0x0000);
                loop_count++;
            }
            else
            {
                readOnCpuBus(0x0000);
                test_state = 10;
                loop_count = 0;
            }
            break;


        case 10:
            readOnCpuBus(0x5204);  // Clear scanline IRQ
            test_state++;
            break;
        case 11:
            writeOnCpuBus(0x5203, 1);  // Set scanline # on which to generate interrupt
            test_state++;
            break;
        case 12:
            writeOnCpuBus(0x5204, 0x80);  // Enable scanline interrupt
            PPU_A13_N = 0;  // Set PPU address to $2000 (in range)
            test_state = 20;//++;
            break;
        case 13:
            readOnCpuBus(0x0000);
            test_state = 20;
            break;
           
        case 20:  // PPU read in range
            PPU_RD_PIN = 0;
            asm(" repeat #12 \n\t nop ");
            readOnCpuBus(0x0000);
            asm(" repeat #12 \n\t nop ");
            PPU_RD_PIN = 1;
            test_state++;
            break;
        case 21:  // PPU read same
            PPU_RD_PIN = 0;
            asm(" repeat #12 \n\t nop ");
            readOnCpuBus(0x0000);
            asm(" repeat #12 \n\t nop ");
            PPU_RD_PIN = 1;
            test_state++;
            break;
        case 22:  // PPU read same
            PPU_RD_PIN = 0;
            asm(" repeat #12 \n\t nop ");
            readOnCpuBus(0x0000);
            asm(" repeat #12 \n\t nop ");
            PPU_RD_PIN = 1;
            asm(" repeat #12 \n\t nop ");
            PPU_A13_N = 1;  // Set PPU address to $0000 (out of range)
            test_state++;
            break;
        case 23:  // PPU read out of range
            PPU_RD_PIN = 0;
            asm(" repeat #12 \n\t nop ");
            readOnCpuBus(0x0000);
            asm(" repeat #12 \n\t nop ");
            PPU_RD_PIN = 1;
            asm(" repeat #12 \n\t nop ");
            PPU_A13_N = 0;  // Set PPU address to $2000 (in range)
            if( loop_count < 241 )
            {
                loop_count++;
                test_state = 20;
            }
            else
            {
                readOnCpuBus(0x0000);
                loop_count = 0;
                test_state = 10;
            }
            break;
    }
   
    IFS0bits.T1IF = 0;  // Clear Timer1 interrupt flag.
}



Edit:

It seems more like a setup or code issue now because when I add this step (MMC5A timer IRQ):
Code:
(case 2 changed to do test_state++)
        case 3:
            writeOnCpuBus(0x5209, 0x20);  // Timer IRQ
            test_state = 10;
            break;


/IRQ still stays high.


Edit 2:

Verified that I can still read and write to the multiplier. This means the MMC5A is running and the CPU bus is fully functional. I ohmed out /IRQ back through to my breakout board, no problems. No positive or negative M2 pulses greater than 100 usec. I wonder why I can't get any IRQs?? I have never looked at /IRQ before now actually.


Edit 3:

I reverted my code and I DID get the timer /IRQ to work. So now I have a starting point to debug this. I think I'm pretty much snowed in at work tonight so I might have all sorts of time to kill working on this.


Edit 4:

Figured out my bug. I always forget, my CPU address bus gets inverted by my level shifters. In the read and write, I should have had:
OUTP_CPU_ADDRESS_BUS = (address ^ 0x7FFF);

This fixed it and I am now tricking the MMC5 to generate scanline interrupts. Will continue investigating and experimenting.


Edit 5:

Fascinating discovery. I noticed that my /IRQ was going back high momentarily in my 300 scanline loop. I blew that loop out to 5000 and captured with my scope. I find that the /IRQ automatically goes back high each 241 scanlines, and after that, triggers low again after the specified number of scanlines. I changed the value loaded into $5203, and the re-trigger of /IRQ followed the new value. In this loop, /IRQ goes high, goes low after x cycles ($5203) and then goes back high again, exactly 241 scanlines from the last time it went high.

Also, this proves that the value loaded into $5203 is preserved and not directly decremented as the wiki alludes to.


Edit 6:

It looks like the MMC5 generates an IRQ after detecting +2 from the number specified in $5203. For example, I set $5203 = $01 and the IRQ occurred on the 3rd scanline detected. Which means that it is not possible to trigger IRQ on the prerender scanline or on scanline 0.

When doing the 241-scanline auto-release of /IRQ, it retriggers exactly after the number specified by $5203, not +2. I am not sure what that means or if it is a realistic situation, but maybe it means something.

Attachment:
scanline_counter.png
scanline_counter.png [ 60.55 KiB | Viewed 865 times ]

Attachment:
retrigger scanline.png
retrigger scanline.png [ 37.54 KiB | Viewed 865 times ]



Edit 7:

I find that I do not have to write to $5203 again. It remembers the value. After I clear the /IRQ within the simulated v-blank, the IRQ occurs again on the correct scanline of the next frame.


Edit 8:

In the v-blank simulation period, where I had lots of M2 rising edges with PPU /RD high to get the top state machine into state 3, I reduced my M2 rising edges. When I went below 3, the 241-scanline rollover started kicking in, indicating that v-blank was no longer being detected by the MMC5. I now strongly believe that:
- Entering top state machine state 3 resets the scanline counter, i.e. in-frame status bit becomes 0.
- Entering the bottom state machine state 3 increments the scanline counter.

And it looks like this happens on PPU cycle 2 of each scanline (except for the pre-render scanline). This disagrees with the wiki, which states that the scanline IRQ occurs on cycle 0 of the scanline, and that the counter is incrementing somehow at the end of the previous scanline. Could we get into the details where this info came from? There should be a way to test and resolve the difference.


Edit 9:

Even if you simulate more than 241 scanlines between v-blanks, it is not possible to generate an IRQ when setting $5203 higher than 240, because that auto-release IRQ thing kicks in on the 241st scanline. I tried with 260 scanlines and $5203 = 241, /IRQ was always high. Also tried $5203 = 255, no difference.


Edit 10:

When I added a read from $FFFA within my simulated V-blank, then the IRQ occurs 1 scanline earlier. For example, if I set $5203 = 1, it will happen on cycle 2 of scanline 1.

Attachment:
File comment: With read of $FFFA within v-blank, scanline generating interrupt equals value written to $5203. $5203 = 1 shown here.
tek00076.png
tek00076.png [ 49.93 KiB | Viewed 862 times ]



Edit 11:

I think this is bad news for my beloved state machine diagram because I don't see how it captures edit 10. In my sumulated V-blank, I am not touching PPU/RD, and I have returned to already to state 3 (not-in-frame). By adding an additional read from $FFFA, it should make no difference according to this diagram -- the top state machine should stay in state 3 and the bottom state machine should remain unaffected.

This seems to suggest that the bottom state machine returns to unlocked state when reading $FFFA/B, which in itself increments the scanline counter, offsetting by this extra count observed. If this is true, it means that the next falling edge of /RD after reading $FFFA/B, regardless of any other condition or sequence, will set the "in frame" status bit back to 1. I am pretty sure that is not what we observed.


Edit 12:

False alarm. Whewww. It did not make any difference whether I read $FFFA/B. It always generates IRQ on the scanline in $5203 now. I am no longer able to recreate where it did the +1 I was seeing earlier, I am not quite sure what happened. I definitely changed too many things at once to keep track. I am updating the code above to the code I am using now.


Edit 13:

Shown here, I have $5203 set to 3. On the left I cause the MMC5 to reset the scanline counter via M2 rising edges with PPU /RD = 1. i.e., stepping through each state across the top state machine. On the right, I cause the MMC5 to reset the scanline counter by reading $FFFA. The behavior is shown to be the same in both cases, and consistent with the state diagrams.

Attachment:
tek00077.png
tek00077.png [ 51.08 KiB | Viewed 861 times ]


Top
 Profile  
 
PostPosted: Wed Feb 06, 2019 4:56 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
Taking some time now to reflect on yesterday's experiments. Bottom state machine, going from unlocked to locked (i.e. state 3 to state 0), is what increments the scanline counter. Known fact from all of this, never found anything that disagrees with that.

This means that you read 3 consecutive matching PPU addresses in range $2xxx, followed by any number of additional PPU addresses, matching or not, in the range $2xxx. THEN any read outside the range $2xxx increments the scanline counter, in practice placing the IRQ actually on cycle 4 of the scanline. Simple enough, follows the diagram, we're happy.

However, I am not able to explain or reproduce the first screenshot in the previous post where it apparently did something else and was off by 1 extra scanline. I need to make it do that again somehow and try to explain it.

Another unknown: Does the top state machine reset the scanline counter when going from "in-frame" = 1 to 0, or from 0 to 1? It seems like 1 to 0 but was not investigated/confirmed.

One more note about the last screenshot, where I did both a simulated V-blank with 3 M2 rising edges with PPU /RD high, vs. reading from CPU $FFFA. I did not clear the interrupt in that test with the $FFFA. Reading it automatically cleared the IRQ back high on its own, similar to reading the 241st scanline. With this behavior, you could take a shortcut if you wanted to generate an IRQ on each N scanlines. For example, set $5203 = 8. Then when you are done in the scanline interrupt, simply read $FFFA and RTI. This will clear the IRQ, reset the scanline counter, and automatically generate another IRQ after 8 more scanlines.


Top
 Profile  
 
PostPosted: Fri Feb 08, 2019 5:13 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
Thanks to MPLabX's built-in history tracking, I was able to recover the old code that had an IRQ on the N+2 scanline. I did reproduce it.

Normally:
$5203 value -> IRQ happens in this scanline#, cycle #4
n/a -> Pre
n/a -> 0
1 -> 1
2 -> 2
3 -> 3
4 -> 4

And in this strange case:
$5203 value -> IRQ happens in this scanline#, cycle #4
n/a -> Pre
n/a -> 0
n/a -> 1
1 -> 2
2 -> 3
3 -> 4

I find that I can get into the strange case by changing the number of CPU reads in the simulated V-Blank with PPU /RD always high. Every multiple of 4 CPU reads inserted in this area causes the +1 offset to the scanline counter. This behavior is definitely not captured in the state diagrams. Neither state machine was previously believed to change any states when exceeding 3 consecutive M2 rising edges with PPU /RD always high. There is either something wrong with the diagram or there is another level of logic missing.

+1 on our understanding of MMC5 scanlines! Will try to narrow this and reconcile it with the status bit behavior.


Last edited by Ben Boldt on Fri Feb 08, 2019 5:26 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri Feb 08, 2019 5:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
Ben Boldt wrote:
by changing the number of CPU reads in the simulated V-Blank with PPU /RD always high. Every multiple of 4 CPU reads inserted in this area causes the +1 offset to the scanline counter.
O_o

Just to be clear: what exactly are you having /ROMSEL, M2, and R/W ... and I guess the whole address bus, really ... doing in this period?


Top
 Profile  
 
PostPosted: Fri Feb 08, 2019 5:30 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
lidnariq wrote:
Ben Boldt wrote:
by changing the number of CPU reads in the simulated V-Blank with PPU /RD always high. Every multiple of 4 CPU reads inserted in this area causes the +1 offset to the scanline counter.
O_o

Just to be clear: what exactly are you having /ROMSEL, M2, and R/W ... and I guess the whole address bus, really ... doing in this period?


This is all hooked directly to a dsPIC microcontroller, with no intervention from the PC. It has the source code loop I pasted above running directly on a hardware timer interrupt with nothing else going on. So it is very repeatable and no delays/lags/etc.

/ROMSEL and the CPU address bus are controlled directly by the PIC, all hooked up. M2, CPU R/W, PPU /RD, and PPU /A13 are also all direct to the PIC. PPU A0-A12 are all tied directly to GND.

When I change "if( loop_count < X )" in case 1 of the code, each 4th value X ends up with the +1 scanline behavior. I tried these values for X:

0 normal
1 normal
2 EXTRA
3 normal
4 normal
5 normal
6 EXTRA
7 normal
8 normal
9 normal
10 EXTRA
11 normal
12 normal
13 normal
14 EXTRA
15 normal
16
17
18 EXTRA

258 EXTRA
259 normal

65538 EXTRA (Note: in this case I changed to uint32_t type for loop_count.)
65539 normal


Top
 Profile  
 
PostPosted: Fri Feb 08, 2019 5:56 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
Maybe it cares how many M2s here in order to determine NTSC vs. PAL for some reason? Or maybe different PPUs have 2 prerender scanlines or something and it wants to skip an extra one? We only have 1 PPU timing diagram, for NTSC -- do we know the differences? Maybe that could shed some light.


Top
 Profile  
 
PostPosted: Fri Feb 08, 2019 6:34 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
Ben Boldt wrote:
OUTP_CPU_ADDRESS_BUS = (address ^ 0x7FFF);
In the NES, it's not /A15, it's literally NAND2(A15,M2). While I don't see how that would matter... I wouldn't dare rule it out.

Quote:
asm(" repeat #12 \n\t nop "); // Setup Delay, so address bus is stable for MMC5 to register the read on M2 rising edge
How fast is this dsPIC running? in other words, how many ns is 12 nops? Sorry for asking a question you may have already answered, but ... you kinda gave me a wall of text.

Quote:
void __attribute__((interrupt, no_auto_psv)) _T1Interrupt( void )
Step 2 in your synopsis is missing in your code, but I agree that it shouldn't matter.


What I'm really getting at is that the behavior you describe is incredible, because if a naive interpretation of what you say you observed were true, the MMC5 scanline IRQ would be unusable.

So I have to assume experimental error, but your notes are a sufficiently dense wall of text that I am having difficulty figuring out exactly what happened.

Quick things to test: Do other addresses other than 0 also cause the incorrect IRQ delay?


Top
 Profile  
 
PostPosted: Fri Feb 08, 2019 7:53 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
lidnariq wrote:
Ben Boldt wrote:
OUTP_CPU_ADDRESS_BUS = (address ^ 0x7FFF);
In the NES, it's not /A15, it's literally NAND2(A15,M2). While I don't see how that would matter... I wouldn't dare rule it out.

Okay, can change the test to behave this way.

lidnariq wrote:
Quote:
asm(" repeat #12 \n\t nop "); // Setup Delay, so address bus is stable for MMC5 to register the read on M2 rising edge
How fast is this dsPIC running? in other words, how many ns is 12 nops? Sorry for asking a question you may have already answered, but ... you kinda gave me a wall of text.

The dsPIC is running at ~40 MHz. I will measure the 12 nop delay for you.

lidnariq wrote:
Quote:
void __attribute__((interrupt, no_auto_psv)) _T1Interrupt( void )
Step 2 in your synopsis is missing in your code, but I agree that it shouldn't matter.

Yes, my bad. I had edited and updated the code but not the synopsis. You can consider the synopsis outdated in that post.

lidnariq wrote:
What I'm really getting at is that the behavior you describe is incredible, because if a naive interpretation of what you say you observed were true, the MMC5 scanline IRQ would be unusable.

So I have to assume experimental error, but your notes are a sufficiently dense wall of text that I am having difficulty figuring out exactly what happened.

Quick things to test: Do other addresses other than 0 also cause the incorrect IRQ delay?

Sorry I did put a lot of text up there, I wanted to capture every detail. I do these things after work before I go home, log it here, then I read it carefully on here at home at night so I can spend the time to think through it and plan what to try the next day. I had not taken the time to make my text more short and readable... Was getting hungry and went home.

I will try reading CPU addresses other than $0000 and let you know. Also, I will try doing a read of $FFFA at the beginning of the V-blank and see if that makes any difference. I am as confused as you are about this, it will be interesting to see where it goes. Hopefully it isn't some obscure issue with the way I have things set up, but really it is a pretty straightforward setup and code path. In case it's a real thing, let's continue to brainstorm why it might keep a count of M2 cycles and behave differently in 1 out of each 4 counts.

Isn't this awesome??? We have no idea how to explain this yet! :D


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 334 posts ]  Go to page Previous  1 ... 18, 19, 20, 21, 22, 23  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: FrankenGraphics 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