PowerPak mappers latching data on the rising edge of M2?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
Trirosmos
Posts: 50
Joined: Mon Aug 01, 2016 4:01 am
Location: Brinstar, Zebes
Contact:

PowerPak mappers latching data on the rising edge of M2?

Post by Trirosmos »

Reading through the source for some of Loopy's mapper implementations, I stumbled upon bits of code like this one:

Code: Select all

always@(posedge m2) begin
        if(nesprg_we) begin
            casex({ain[15:12],ain[1:0]})
                6'b1000xx:prgbank8<=nesprgdin;      //800x
                6'b1100xx:prgbankC<=nesprgdin;      //C00x
                6'b101111:mirror<=nesprgdin[3:2];   //B003
                6'b110100:chrbank0<=nesprgdin;      //D000
                6'b110101:chrbank1<=nesprgdin;      //D001
                6'b110110:chrbank2<=nesprgdin;      //D002
                6'b110111:chrbank3<=nesprgdin;      //D003
                6'b111000:chrbank4<=nesprgdin;      //E000
                6'b111001:chrbank5<=nesprgdin;      //E001
                6'b111010:chrbank6<=nesprgdin;      //E002
                6'b111011:chrbank7<=nesprgdin;      //E003
                6'b111100:irqlatch<=nesprgdin;      //F000
                6'b111101:{irqM,irqA}<={nesprgdin[2],nesprgdin[0]}; //F001
            endcase
	end
end
Which should handle writes to mapper registers.
m2 seems to come straight from the console and ain[15] is just the inverted version of /ROMSEL:

Code: Select all

IBUFG b01(.I(NES_M2),.O(m2));
...
IBUF b20(.I(NES_PRG_CE),.O(nesprg_ce));
assign prgain[15]=!nesprg_ce;
Now, as far as I understand, ROMSEL isn't stable until about 20-30 ns after the rising edge of M2. Additionally, on CPU write cycles, the data bus doesn't become stable until much later.

So, my question is: how are these mappers able to function at all? Does the PowerPak introduce some delay to M2 external to the FPGA?
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: PowerPak mappers latching data on the rising edge of M2?

Post by aquasnake »

If there is a real Powerpak (or photograph), you can check the M2 signal to see if there is a inverser (buffer) in the line
User avatar
aquasnake
Posts: 515
Joined: Fri Sep 13, 2019 11:22 pm

Re: PowerPak mappers latching data on the rising edge of M2?

Post by aquasnake »

When M2 rising edge comes, the data lines are not stable.

A15 has a delay of almost 33ns after the rising edge of M2, which depends on the gate delay of romsel generation circuit. An NOAC has very short delay and better compatibility.

It is not a good method to use M2 rising edge latch strictly. Even if the address is locked, A15 will be misjudged. That is to say, if the address lines are used to be locked, A15 must be ignored, and the locked A15 may not be the exact state of the internal bus. A15/romsel can only be used as the input condition of the latch, but not as the stored value of the latch.

Powerpak does not simply latch at the rising edge of M2, it has a digital filtering of M2, and even has been inverted internally.
Trirosmos
Posts: 50
Joined: Mon Aug 01, 2016 4:01 am
Location: Brinstar, Zebes
Contact:

Re: PowerPak mappers latching data on the rising edge of M2?

Post by Trirosmos »

aquasnake wrote: Mon May 31, 2021 10:25 pm Powerpak does not simply latch at the rising edge of M2, it has a digital filtering of M2, and even has been inverted internally.
That would make sense. However, I can't seem to find in the PowerPak source where that happens.
Now, powerpak.v does have this signal:

Code: Select all

    reg [1:0] m2buf;
    always@(posedge clk20)
        m2buf<={m2buf[0],m2};
    wire m2_n = ~m2 & ~m2buf[1];    // m2 with a delayed falling edge, to deal with addressing glitches
And it does seem some use in Loopy's MMC3 implementation in enabling or disabling the memories:

Code: Select all

    assign prgram_oe= ~cfg_boot & m2_n & ~nesprg_we & prgain[15];
    assign wram_oe=               m2_n & ~nesprg_we & prgain[15:13]==3'b011 /* & wramen[1] */;
    assign wram_we=m2_n & nesprg_we & prgain[15:13]=='b011 /* & wramen==2 */;   //wram protection breaks startropics / startropics2
Which, again, does make sense. However, per my original post, that does not seem to be the signal that is used to latch data from the CPU when writing to mapper registers. powerpak.v also says " //all signals active high ", so...
User avatar
loopy
Posts: 405
Joined: Sun Sep 19, 2004 10:52 pm
Location: UT

Re: PowerPak mappers latching data on the rising edge of M2?

Post by loopy »

aquasnake wrote: Mon May 24, 2021 1:27 am If there is a real Powerpak (or photograph), you can check the M2 signal to see if there is a inverser (buffer) in the line
This. M2 is inverted before it gets to the FPGA.
Trirosmos
Posts: 50
Joined: Mon Aug 01, 2016 4:01 am
Location: Brinstar, Zebes
Contact:

Re: PowerPak mappers latching data on the rising edge of M2?

Post by Trirosmos »

loopy wrote: Fri Jun 04, 2021 8:20 am
aquasnake wrote: Mon May 24, 2021 1:27 am If there is a real Powerpak (or photograph), you can check the M2 signal to see if there is a inverser (buffer) in the line
This. M2 is inverted before it gets to the FPGA.
Aaah, alright, that does clear things up!
Thanks! :)
Post Reply