Curious about MMC5 5209/520A registers
Moderator: Moderators
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
Curious about MMC5 5209/520A registers
Hey there. I was just curious about this "hardware timer" thing with 5209/520A registers for IRQ's.
On here:
http://wiki.nesdev.com/w/index.php/MMC5 ... A_write.29
Is there any real general purpose use where one could use this for some cool effect or anything ? First of all i cant figure out from the nesdev wiki what the timer repersents exactly. Like if you do 0001 to the registers, does an IRQ start after 1 scanline, 1 frame, 1 PPU cycle ?? ... 1 "what" ?? The wiki is not clear on "what" that actually means.
"m2 rising edge" means nothing to me, sorry. I dont have a clue what that means or how many cycles or whatever, it repersents.
I was testing it out like doing 0001 ..or 0100 like in the example, then keep clicking "step into" button on fceux debugger dozens of times ...or for many scanlines, but never once does an IRQ ever trigger. So i dont understand.
Im guessing fceux 2.15 (which i use) ..does not have these registeres implemented huh ?? I also tried looking with nintendulator's debugger stepping 1 line at a time after the 5209/520A writes, but nothing ..guess that emu dont support it either ? I dont know.
Guessing it's not really any useful for doing irq effects ?? Cause usually you always gotta time your effects between the "ppu dot 250 to 341" thing anyways with NOP's ..
I have an extremely critically timed wavy water effect in Pyro Man level on my megaman odyssey game that "only" looks fine in fceux, but no other emulators unfortantely.
On here:
http://wiki.nesdev.com/w/index.php/MMC5 ... A_write.29
Is there any real general purpose use where one could use this for some cool effect or anything ? First of all i cant figure out from the nesdev wiki what the timer repersents exactly. Like if you do 0001 to the registers, does an IRQ start after 1 scanline, 1 frame, 1 PPU cycle ?? ... 1 "what" ?? The wiki is not clear on "what" that actually means.
"m2 rising edge" means nothing to me, sorry. I dont have a clue what that means or how many cycles or whatever, it repersents.
I was testing it out like doing 0001 ..or 0100 like in the example, then keep clicking "step into" button on fceux debugger dozens of times ...or for many scanlines, but never once does an IRQ ever trigger. So i dont understand.
Im guessing fceux 2.15 (which i use) ..does not have these registeres implemented huh ?? I also tried looking with nintendulator's debugger stepping 1 line at a time after the 5209/520A writes, but nothing ..guess that emu dont support it either ? I dont know.
Guessing it's not really any useful for doing irq effects ?? Cause usually you always gotta time your effects between the "ppu dot 250 to 341" thing anyways with NOP's ..
I have an extremely critically timed wavy water effect in Pyro Man level on my megaman odyssey game that "only" looks fine in fceux, but no other emulators unfortantely.
Re: Curious about MMC5 5209/520A registers
One CPU cycle. Specifically, about 1/3 of the way into one.kuja killer wrote: ↑Thu Jan 16, 2020 5:43 pm "m2 rising edge" means nothing to me, sorry. I dont have a clue what that means or how many cycles or whatever, it represents.
No games rely on it, no emulators support it. It's only present in the MMC5 "A" revision, so it's even more of a bad idea than targeting the MMC5 is in the first place.I was testing it out like doing 0001 ..or 0100 like in the example, then keep clicking "step into" button on fceux debugger dozens of times.
Because the MMC5 already provides a separate IRQ triggered by the PPU, the separate CPU-clocked IRQ is really only useful for two thingsGuessing it's not really any useful for doing irq effects ?
1- Things that are entirely unrelated to graphics but require regular timing, such as streaming audio to a DAC. BUT, one still would have timing conflicts with OAMDMA, so there will be unavoidable artifacts for any sample rate that one might want. (At the sufficiently slow speeds where such artifacts wouldn't occur, one'd be better off just using DPCM instead.)
2- Things that need to happen while the PPU is not rendering, such as increasing the amount of blanking time at the top of the screen, after NMI.
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
Re: Curious about MMC5 5209/520A registers
Oh i see, no emu's. Okay then, oh well.
So then just to clarify... a 0001 would of made an IRQ literally the instant you write it to the registers just because it's 1 CPU cycle ?? (like right after the STA 5209, and before the next opcode literally) ?
Should mention that on the wiki ...cause i dont think many people like me would understand "next m2" thing. Telling how many cpu cycles would be easier to understand.
So then just to clarify... a 0001 would of made an IRQ literally the instant you write it to the registers just because it's 1 CPU cycle ?? (like right after the STA 5209, and before the next opcode literally) ?
Should mention that on the wiki ...cause i dont think many people like me would understand "next m2" thing. Telling how many cpu cycles would be easier to understand.
Re: Curious about MMC5 5209/520A registers
I think that "feature" was a very recent discovery that wasn't known a few years ago. That's why no (widely distributed) emus simulate it.Oh i see, no emu's. Okay then, oh well.
Don't hesitate to fix the wiki yourself. These informations are in the form of a wiki for a reason.kuja killer wrote: ↑Thu Jan 16, 2020 9:35 pm Oh i see, no emu's. Okay then, oh well.
So then just to clarify... a 0001 would of made an IRQ literally the instant you write it to the registers just because it's 1 CPU cycle ?? (like right after the STA 5209, and before the next opcode literally) ?
Should mention that on the wiki ...cause i dont think many people like me would understand "next m2" thing. Telling how many cpu cycles would be easier to understand.
Also on the MMC5, increasing blanking time makes less sense than on other mappers. MMC5 (officially) only supports CHR-ROM so you won't have to rewrite large pattern tables. Also, to write large nametable data, you can use the ExRAM which is writable during the frame.2- Things that need to happen while the PPU is not rendering, such as increasing the amount of blanking time at the top of the screen, after NMI.
Re: Curious about MMC5 5209/520A registers
But only if you're either displaying from the other nametables during rendering, or if you're ok with screen tearing. Either way, access to the NES-internal nametables is still pretty bandwidth limited.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Curious about MMC5 5209/520A registers
I didn't know that.Bregalad wrote:MMC5 (officially) only supports CHR-ROM
Re: Curious about MMC5 5209/520A registers
I'm not clear what "officially" means. Other than maybe that Nintendo never released a PCB with a space for a RAM...?
Certainly subsequent romhacks have established that the IC itself has no problem with CHR RAM.
Certainly subsequent romhacks have established that the IC itself has no problem with CHR RAM.
Re: Curious about MMC5 5209/520A registers
Yeah that's what I meant.
Well there's the FF1 romhack, which I don't know whether it works on real hardware. The new FF3 retranslation abandonned MMC5+CHR-RAM precisely because it was glitchy and unreliable.Certainly subsequent romhacks have established that the IC itself has no problem with CHR RAM.
Also ExRAM makes it benefit from advantages of CHR-RAM while still using CHR-ROM. You can have tiles from all the whole game on the screen at once.
Re: Curious about MMC5 5209/520A registers
People have made reproductions of the Rockman 4 Minus Infinity romhack, which requires CHR RAM, so it certainly seems to work.
It's difficult to design a mapper that makes CHR RAM impossible. More-or-less the only thing that occurs to me is things that modify the contents of the data bus between the memory and the PPU, such as left-to-right reflection of tiles or palette swaps.
Specific silicon could be designed to be prohibitive in one way or another, such as only emitting the right value on its CHR banking pins while /RD is low (but why??).
It's difficult to design a mapper that makes CHR RAM impossible. More-or-less the only thing that occurs to me is things that modify the contents of the data bus between the memory and the PPU, such as left-to-right reflection of tiles or palette swaps.
Specific silicon could be designed to be prohibitive in one way or another, such as only emitting the right value on its CHR banking pins while /RD is low (but why??).
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: Curious about MMC5 5209/520A registers
Nintendo's leaked lot check spreadsheets have an interesting unreleased MMC5 game entry: a cartridge conversion of "Famicom Mukashibanashi: Shin Ongashima". It is listed as having used a "HVC-ENROM" circuit board with 256 KiB of PRG-ROM, 8 KiB of PRG-RAM, 8 KiB of CHR-RAM, a battery, and this comment: "情報開発部 ※…バックアップRAMはMMC-5内蔵RAMのみを使用。", machine-translated as "Information Development Department *… Use only MMC-5 built-in RAM for back-up RAM."
This suggests that the MMC5 would have accepted CHR-RAM on an "ENROM" board.
This suggests that the MMC5 would have accepted CHR-RAM on an "ENROM" board.
Re: Curious about MMC5 5209/520A registers
Wow, that's a shocking informationNewRisingSun wrote: ↑Fri Jan 17, 2020 2:24 pm Nintendo's leaked lot check spreadsheets have an interesting unreleased MMC5 game entry: a cartridge conversion of "Famicom Mukashibanashi: Shin Ongashima". It is listed as having used a "HVC-ENROM" circuit board with 256 KiB of PRG-ROM, 8 KiB of PRG-RAM, 8 KiB of CHR-RAM, a battery, and this comment: "情報開発部 ※…バックアップRAMはMMC-5内蔵RAMのみを使用。", machine-translated as "Information Development Department *… Use only MMC-5 built-in RAM for back-up RAM."
This suggests that the MMC5 would have accepted CHR-RAM on an "ENROM" board.
So yeah I guess this nullifies my above comments (as well as many older posts saying something in the same direction).
EDIT: Do you have any link to said leaked spreadsheet ? I only remember one about the MMC1 and PPU being leaked.
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
Re: Curious about MMC5 5209/520A registers
Hmm that's pretty interesting what you guys are saying. Yea i was going to say, dont forget 4 MI, which is the base megaman 4 ... with CHR-RAM, and mmc5 mapper too.
I have a couple other questions then too if I may. -- I'm assuming the 5800-5BFF stuff is not supported in any emulators too ?? even though little to nothing is known about it. I remember seeing those 5800 STA's or whatever, on the Just Breed rom years ago before I ever saw it mentioned on the wiki itself. Made me go like "woa what's that do?"
About EXRAM, -- ya know how like PPU 23C0-23FF is for the current nametable's palettes, -- is 5FC0-5FFF "not" used for the EX attributes ?? Since that's not technically part of the visible screen you see, i've ex-cluded that that last 40 bytes from all my screen drawing routines so it doesnt get written to.
(i always use the EX attributes stuff like 99% of the time in my megaman romhack)
I have a couple other questions then too if I may. -- I'm assuming the 5800-5BFF stuff is not supported in any emulators too ?? even though little to nothing is known about it. I remember seeing those 5800 STA's or whatever, on the Just Breed rom years ago before I ever saw it mentioned on the wiki itself. Made me go like "woa what's that do?"
About EXRAM, -- ya know how like PPU 23C0-23FF is for the current nametable's palettes, -- is 5FC0-5FFF "not" used for the EX attributes ?? Since that's not technically part of the visible screen you see, i've ex-cluded that that last 40 bytes from all my screen drawing routines so it doesnt get written to.
(i always use the EX attributes stuff like 99% of the time in my megaman romhack)
Re: Curious about MMC5 5209/520A registers
It'd be hard to have an emulator do anything with it, because there's nothing connected there by default.kuja killer wrote: ↑Fri Jan 17, 2020 3:17 pm I have a couple other questions then too if I may. -- I'm assuming the 5800-5BFF stuff is not supported in any emulators too ?? even though little to nothing is known about it. I remember seeing those 5800 STA's or whatever, on the Just Breed rom years ago before I ever saw it mentioned on the wiki itself. Made me go like "woa what's that do?"
Each of the two pins can be configured to be GPIO or an enable to external part.
Given a physical PCB, one could connect a CompactFlash card in that memory region. Or a sound chip, or a RAM or ROM. (There's a lot of options: all that matters is the device not need more than 1024 addresses dedicated to it)
The developers of Just Breed probably connected a latch to that region to track CPU usage, the same way we use the emphasis bits now.
It'll be used for extended attributes on an invalid Y scroll (>=240). Note that all invalid Y scrolls will incorrectly double-clock the MMC5's scanline IRQ on the scanlines where the attribute byte and nametable byte are fetched from the same location (i.e. trying to draw the tile at $23FF, but only for certain X scrolls?).About EXRAM, -- ya know how like PPU 23C0-23FF is for the current nametable's palettes, -- is 5FC0-5FFF "not" used for the EX attributes ?? Since that's not technically part of the visible screen you see, i've ex-cluded that that last 40 bytes from all my screen drawing routines so it doesnt get written to.
(see: Drag's test and loopy's video of hardware. As far as I know, no emulator - not even Mesen - handles this edge case correctly yet.)
(edit: And obviously, ExRAM will use those bytes for an ordinary attribute table if you ever use the left-and-right split screen, or use ExRAM as an ordinary nametable)
Re: Curious about MMC5 5209/520A registers
MMC5 ExGrafix lets you use tiles from an entire 256 KiB block, but it doesn't let you compose glyphs at non-8x8-pixel boundaries. Thus if you want a proportional font with CHR ROM, you have to prerender all your strings when building the ROM.
-
- Posts: 130
- Joined: Mon May 25, 2009 2:20 pm
Re: Curious about MMC5 5209/520A registers
Ah okay. Too bad about the 5800-5BFF area then. going unused pretty much.
Yea well, i'll never be using Scroll F0-FF anywhere anyways. I use Y position E8 on a few of the menu screens like Time Attack, Achivements, and Save-Load Game screens.
Never F0+ though cause it creates a empty black line at the top of the screen, that must be what your referring to. Or maybe that's the actual real 5FC0-5FFF part.
And i've never used it as that "3rd nametable" ever before. I highly doubt i ever will in the future. I know it'd be probably nice for certain situations/screens though. I wish it was able to be a 2nd background layer like SNES/Genesis.
Tepples - That's what i truly love about EX Att. being able to set any individual tile's graphic page from anywhere you want in the ROM. it allows levels to have hundreds more "unique" tiles anywhere-anytime without ever needing to manually swap the actual graphic page number anywhere. And of course the "palette to 8x8 tile" instead of 16x16
Necro Man has something like 700 to 800 (3 whole 256-tile pages worth) of unique graphic tiles at once, thanks to those EX Att's
Yea well, i'll never be using Scroll F0-FF anywhere anyways. I use Y position E8 on a few of the menu screens like Time Attack, Achivements, and Save-Load Game screens.
Never F0+ though cause it creates a empty black line at the top of the screen, that must be what your referring to. Or maybe that's the actual real 5FC0-5FFF part.
And i've never used it as that "3rd nametable" ever before. I highly doubt i ever will in the future. I know it'd be probably nice for certain situations/screens though. I wish it was able to be a 2nd background layer like SNES/Genesis.
Tepples - That's what i truly love about EX Att. being able to set any individual tile's graphic page from anywhere you want in the ROM. it allows levels to have hundreds more "unique" tiles anywhere-anytime without ever needing to manually swap the actual graphic page number anywhere. And of course the "palette to 8x8 tile" instead of 16x16
Necro Man has something like 700 to 800 (3 whole 256-tile pages worth) of unique graphic tiles at once, thanks to those EX Att's
Last edited by kuja killer on Fri Jan 17, 2020 6:12 pm, edited 1 time in total.