What happens to the IRQ counter if you play one of those games in a PAL system?
Is it clocked at NTSC CPU speed, or PAL CPU speed?
Is it clocked at NTSC CPU speed, or PAL CPU speed?
Since it's driven by cpu cycles it's driven by whatever clock rate the CPU runs at. This means that one "scanline" is no longer a real scanline, so the IRQ counter wouldn't work very well on PAL systems.
Disch wrote:
Since it's driven by cpu cycles it's driven by whatever clock rate the CPU runs at. This means that one "scanline" is no longer a real scanline, so the IRQ counter wouldn't work very well on PAL systems.
(Programmer's perspective) Would it work on a PAL NES if you multiply all scanline counts by 15/16 before passing them to the VRC?
Yes but then the timing is off so it really sucks badly. That's why I've always been against Konami VRC mappers.
I know the irq counter in MMC3 for instance is not cpu driven but ppu driven, i.e. it sees when the ppu retrieves the sprites at the beginning of every line by watching ?A13?
I once heard that MMC3 is a more-featured clone of one of konami's early mappers, so it wouldn't surprise me if the konami mappers also do the same ppu-address-watching thing to count scanlines.
I could be wrong though.
LN
I once heard that MMC3 is a more-featured clone of one of konami's early mappers, so it wouldn't surprise me if the konami mappers also do the same ppu-address-watching thing to count scanlines.
I could be wrong though.
LN
Konami VRC4 and up count CPU cycles they do not use the PPU at all. You can clearly observe this behavior by the way the games set the IRQ target number at NMI if I recall as that is the frame of reference point you have to set it at. Also it's known that the counter counts even if rendering is off or not happening.
Lord Nightmare wrote:
I know the irq counter in MMC3 for instance is not cpu driven but ppu driven, i.e. it sees when the ppu retrieves the sprites at the beginning of every line by watching ?A13?
MMC3 watches for a pulse (or string of closely spaced pulses) on A12. The nametables live in $2000-$2FFF (A12=0), and the patterns used for the backgrounds are in $0000-$0FFF (A12=0). The patterns used for sprites are in $1000-$1FFF, which sets A12 to 1 and clocks the counter.
Quote:
I once heard that MMC3 is a more-featured clone of one of konami's early mappers
It was a Namco 109 mapper, the one used in D*ROM. Tengen used it and called it MIMIC-1.
Code:
It was a Namco 109 mapper, the one used in D*ROM. Tengen used it and called it MIMIC-1.
Yeah and that early verion of MMC3 has only the default CHR ROM and PRG ROM bankswitching. It lacks the alternate switching shemes, IRQ counter and mirroring control.
MMC3's counter uses A12 which sucks because it forces you to use sprites on the right pattern table and BG on the left, and Konami VRC mappers uses M2 which sucks because it was designed for NTSC only. A good counter would use A13 (like the MMC5 I think).
Bregalad wrote:
MMC3's counter uses A12 which sucks because it forces you to use sprites on the right pattern table and BG on the left, and Konami VRC mappers uses M2 which sucks because it was designed for NTSC only. A good counter would use A13 (like the MMC5 I think).
An A13 based counter would require exactly 42 fetches per line (34 bg and 8 sprite), restricting Nintendo's ability to make backward-compatible improvements to the PPU. These might have included doubling the secondary OAM and cutting out the dummy nametable fetches before sprite pattern fetches to allow 16 sprites per line, or a second VRAM port for accesses during draw like on the TG16. You can see this in NOAC famiclones, which tend not to run MMC5 games because their fetch pattern isn't exactly the same as that of an authentic 2C0x PPU.
EDIT: fixed typo
tepples wrote:
16 sprites per line
That would be awesome on the NES.
Quote:
You can see this in NOAC famiclones
Do you know what extra features are available in the NOAC and how to access them? And also what clones use the NOAC in question? Just curious, as I probably wouldn't make a NOAC-specific game.
Quote:
An A13 based counter would require exactly 42 fetches per line (34 bg and 42 sprite), restricting Nintendo's ability to make backward-compatible improvements to the PPU.
Well so far they haven't made any and they VERY probably never will.
Quote:
These might have included doubling the secondary OAM and cutting out the dummy nametable fetches before sprite pattern fetches to allow 16 sprites per line, or a second VRAM port for accesses during draw like on the TG16.
Some games actually abuse the 8-sprite limitation to do clipping.
Bregalad wrote:
Some games actually abuse the 8-sprite limitation to do clipping.
That was exactly my problem in NESICIDE emulator with Link walking over the dungeon doors in Zelda...
I emulated setting the overflow flag but not stopping sprite rendering on the scanline because of it.
Doesn't he mean 42 fetches per scanline, 34 background and 8 sprite (not 42 sprite)?
Bregalad wrote:
Quote:
An A13 based counter would require exactly 42 fetches per line (34 bg and 42 sprite), restricting Nintendo's ability to make backward-compatible improvements to the PPU.
Well so far they haven't made any and they VERY probably never will.
That wasn't so clear during the NES's commercial era. The Super Famicom/NES was originally slated to have NES back-compat.
^^ Actually they planned on redesigning the famicom iirc. Then that could be plugged into the snes as a video passtrough. But I wouldnt be surprised if they wanted to port a few games. And allow games in development to be ported as well.
Quote:
That wasn't so clear during the NES's commercial era. The Super Famicom/NES was originally slated to have NES back-compat.
If the MMC5 relies on fetches of the PPU, I don't see why any other mapper shouldn't. (not counting how many games relies on precise timings for raster effects)
Bregalad wrote:
If the MMC5 relies on fetches of the PPU, I don't see why any other mapper shouldn't.
Because NOAC-based consoles, such as one that combines clones of an NES, Super NES, and Mega Drive, now outnumber used authentic NES consoles in locally owned retro-gaming shops such as McVan's Video Games.
tokumaru wrote:
tepples wrote:
16 sprites per line
That would be awesome on the NES.
Indeed it would. While not possible with an unmodified console, it would be possible to hack in a second "slave" PPU which would allow for that. Nintendo's PPU-related patents mention that. However, on the NES board the four PPU EXT pins are all grounded, so you'd have to do some reworking. Plus write your own software to take advantage of the feature.
tepples wrote:
That wasn't so clear during the NES's commercial era. The Super Famicom/NES was originally slated to have NES back-compat.
Yes, the SNES PPU1 and PPU2 chips have pins mysteriously called HVCMODE. I always wondered what someone who is handy with a logic analyser could figure out about that feature...
-- M