nesdev.com

Simple question I think. If you set EXRAM to mode 2 where the CPU can read and write to it from $5C00 to $5FFF, can you copy code there and execute it?

I'm trying to do this but Nestopia and Nintendulator seem to say I can't do that. When the CPU try to execute at $5C00 range it seems to get all FFs. However when I copy my routine there, and then read it back I can see in the debugger that each byte was written correctly to EXRAM. To be clear, I copy each byte to EXRAM, then I just loaded each byte from EXRAM back into Reg-A and so through the debugger I could see it was written correctly. But the CPU when watched in the debugger will jump to $5C00 and read FF through the whole region.

So can the CPU for some reason not execute from EXRAM? The reason I'm doing this is I wanted to avoid using PRG-RAM so I could use the MMC-5 board without any.

I hope someone knows the answer to this or can do their own test.

Well, if you can read it then definitely you should be able to execute code from it (but I never tried). Definitely the emulators should be wrong on this point. After all executing code is a particular case of reading !

_________________
Life is complex: it has both real and imaginary components.

Well, if someone doesn't beat me to it first, I'll put together a decent test ROM or someone could modify a demo of theirs to use MMC5 and store a routine in EXRAM and see what happens on the NES. If you try it on Nestopia or Nintendulator it should crash (the NES program) though.

I agree with you, I think this is the emulator at fault as I don't see why EXRAM shouldn't be able to hold code. But the real hardware will have to be tested unless someone else has already tried this.

Does the NES cartridge connector expose any signals which the MMC5 could use to differentiate opcode from data memory accesses? I couldn't find much information about M2.

Not only is there no signal to detect opcode reads (called SYNC) on the connector but the signal isn't available on the 2A03 at all, so without a doubt you can execute from any memory on any mapper.

Well then, Nintendulator and Nestopia both fail to emulate execution from EXRAM. Anyone interested in fixing either? Preferably Nintendulator for it's debugger but either would be useful to me. I'd try to do it myself but I rarely have much luck compiling other people's projects. That and I don't know why they are broken.

There's no reason I can think of why EXRAM cannot be used for code execution. The fact that Nestopia fails is likely due to optimizations designed at fetching instructions as quickly as possible. Those optimizations may not account for the possibility of special memory such as EXRAM. Nintendulator might have a similar problem - don't know what kinds of optimizations that emu uses.

If I get around to it, I will get the latest Nestopia source and see what I can find.

I saw in the MMC5 EXRam thing that you can only read/write to EXRam during rendering, is that right or a typo? Maybe that has something to do with it. And if that's true, you you have to make the next screen for your game in EXRam during the frame outside of vblank?

It depends on the settings you choose. There's a mode that behaves like that, yes, but you can also make it behave just like regular RAM.

So I take it the mode that you can only write during rendering is the mode where you extend the table attributes?.....Why must you write during rendering? Wouldn't that cause the PPU and CPU be trying to use both at the same time, so shouldn't you be trying to change it during VBlank?

You write to it directly via the CPU, instead of using 2006/2007 like when you're trying to access the internal PPU ram. However, we don't actually understand the MMC5 very well at all to know how exactly this is able to work. The MMC5 must do something to allow simultaneous accesses to the ExRAM though, since Nintendo made the decision to only allow writes (in mode 0 and mode 1) during rendering, which is when the PPU is constantly fetching bytes, meaning the MMC5 would need to also be constantly accessing its ExRAM.

My hypothesis is that there's a pipeline, much like the read-pipeline in the PPU when you read 2007. When you write to ExRAM, the MMC5 stores it in the pipeline until the PPU is in between ExRAM accesses, during which it commits the write the CPU made. There are 3 PPU cycles for each CPU cycle, and when the PPU is fetching BG tiles, it spends two of its cycles fetching the bitmap data from the pattern table, so the MMC5 probably commits ExRAM writes during this time. There's a LOT of time in between sequential CPU accesses in which the MMC5 can commit writes, so this would work out flawlessly. This is just a hypothesis though, so don't take this to heart.

But outside of rendering, wouldn't the pipeline just be more efficient and still work?

Maybe after someone decaps the PPU to get a good set of micrographs, someone might decap an MMC5.

We can hope, we'll need to find a couple of Castlevania 3's though....

CV3 isn't the only MMC5 game. Many MMC5 games exist, much less desirable than CV3.