Page 3 of 3

Re: Porting mmc5 PPU cycle counter from mister_nes

Posted: Mon Feb 22, 2021 7:00 pm
by lidnariq
I think you have to do that for the MMC5's "is_rendering" flag anyway. Yes, you could probably use that.

Re: Porting mmc5 PPU cycle counter from mister_nes

Posted: Tue Feb 23, 2021 12:45 am
by aquasnake
There should be two ways to detect the end of the scanline(or the start of the next scanline):

1. Consecutive detection of two reads on the same PPU address. This requires monitoring all PPU address lines. Here, PPU cycle should be 337-340. After the detection, PPU cycle is at 0.

2. Consecutive detection of 3 reads when ppu_a13=1 & ppu_A12 = 0, it is not required to monitor all PPU addresses. Here PPU cycle should be 337-340, 1. (when PPU cycle is 0, all address lines remain the same as PPU cycle 337-340 at the end of the last scanline, /ppu_rd or /ppu_wr signal is not generated, so the detection is ignored. When the next scan line PPU cycle is 1, the NT byte of the first tile is detected, accumulating to 3 times). After the detection, PPU cycle is at 1

Re: Porting mmc5 PPU cycle counter from mister_nes

Posted: Tue Feb 23, 2021 5:01 am
by aquasnake
During PPU cycle 1-256, the bg tiles are rendered. Each tile needs to be read four times. A total of four bytes are read in,the first byte is nametable, the second is attribute, the third and fourth are pixel bitmap bytes(8x2bit). Eight PPU cycles are a group, and a row of eight pixels of a tile is displayed. Therefore, we can detect 8 PPU cycles as a time unit, and dynamically switch the bank for each row of each tile. 8 pixels are 2 bytes. This kind of switching is not completely accessing on random address, but can only get the offset address in the pattern table by calculating the ID in the nametable and combining with the current scanline number.

If you replace the nametable byte and tile byte (# 0, # 2, # 3 bytes) in 8 PPU cycles, it is vsplit mode. Here the substitution is by bankswitching.
If you replace the attribute byte (# 1 byte) in 8 PPU cycles, it is the ex-attr mode. Here is the real data bus hijacking.

Based on the rendering mode of visible scanline buffer, the final display will delay one scanline.
The BG or SPR tiles of the current line will be filled in the shift register and displayed on the next scanline. So the first line will appear garbage

Re: Porting mmc5 PPU cycle counter from mister_nes

Posted: Tue Feb 23, 2021 1:18 pm
by lidnariq
aquasnake wrote:
Tue Feb 23, 2021 12:45 am
There should be two ways to detect the end of the scanline(or the start of the next scanline):

1. Consecutive detection of two reads on the same PPU address. This requires monitoring all PPU address lines. Here, PPU cycle should be 337-340. After the detection, PPU cycle is at 0.
No, this won't work. During the sprite slivers, the internal PPU address multiplexers aren't driven for the the nametable fetches, and they often show the same address for both the nametable and attribute table fetches.

Re: Porting mmc5 PPU cycle counter from mister_nes

Posted: Wed Feb 24, 2021 11:26 pm
by aquasnake
lidnariq wrote:
Tue Feb 23, 2021 1:18 pm
aquasnake wrote:
Tue Feb 23, 2021 12:45 am
There should be two ways to detect the end of the scanline(or the start of the next scanline):

1. Consecutive detection of two reads on the same PPU address. This requires monitoring all PPU address lines. Here, PPU cycle should be 337-340. After the detection, PPU cycle is at 0.
No, this won't work. During the sprite slivers, the internal PPU address multiplexers aren't driven for the the nametable fetches, and they often show the same address for both the nametable and attribute table fetches.
N8 flash cart detects two 3(it matters) reads on the same address, and the counter is reset and synchronized.

Code: Select all

	always @(negedge ppu_oe)
	begin
		
		ppu_addr_eq <= last_ppu_addr == ppu_addr;
		
		if(last_ppu_addr == ppu_addr & ppu_addr_eq)
		begin
			line_ctr <= 0;
		end
			else
		line_ctr <= line_ctr + 1;
	
		if(line_ctr == 170-1)ppu_line_strobe <= !ppu_line_strobe;
		
		last_ppu_addr <= ppu_addr;
		
		
		if(nt_ce)ppu_nt_strobe <= !ppu_nt_strobe;
	end

Re: Porting mmc5 PPU cycle counter from mister_nes

Posted: Wed Feb 24, 2021 11:34 pm
by lidnariq
I don't know how (edit: only 2 reads) could possibly work. We've measured that all the name+attribute table fetches during sprite slivers are regularly from the same address:
viewtopic.php?p=113288#p113288