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 !
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?
3gengames wrote:
I saw in the MMC5 EXRam thing that you can only read/write to EXRam during rendering
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?
3gengames wrote:
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.
tepples wrote:
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.
CV3 is the cheapest though and by far the most plentiful though, and will less hardware we'd lose less per sacrificed board.
I suppose it doesn't matter since a board or two to potentially clone and fully understand the MMC5 would be well worth it.
You could always use a
Laser Invasion cart. Less than $8.00 USD after shipping
i've actually seen it before on my rom hack where like...if there's no music or sound effects currently playing, just complete silence...
and the EX Attributes need to be updated...and it's still during vblank, then the writes to 5C00-5FFF are just completely ignored.
I've never tried putting code into 5C00-5FFF myself ever before. but i do store and run code from the 6000-7FFF SRAM area - mmc5's extra SRAM pages beyond the normal 8 kb limit. "NOT" the first 8 kb page.
If you just want the MMC5 chip, the cheapest deal is the sangokushi carts at 1$ in japan. The next deal is just breed at 3$. Don't waste some castlevania carts for only the MMC5 chips if you can scrap more dirt cheap cart from elsewhere please. If you do, just send me that CV instead and I will trade it for that bunch of sangokushi I have
So am I right in understanding that the MMC5 has 1 kB of expansion RAM + 0/32/64 kB of PRG-RAM, for a total maximum of 66560 bytes?
Yes, the PRG-RAM are separate SRAM chips on the circuit while the ExRAM is inside the MMC5.
No board with 64k were ever made by Nintendo, they either had the standard 1x8k, or 2x8k, or 1x32k.
But it would be possible to have 2x32k to get 64k in total.
Also all this can be battery backed or not.
Additionally (about 5 years late), there's no reason why the CPU shouldn't be able to execute code from it. In fact, Nintendulator has always been able to do that, despite claims to the contrary earlier in this thread - the only thing that "doesn't work" is that the debugger refuses to display its contents on the grounds that reading from $5000-$5FFF could potentially have side effects (which is absolutely correct in this case).
Shouldn't an emulator be able to distinguish a peek from a read? A peek is what you would get if you would read that memory, but without any side effects from actually reading it.
Dwedit wrote:
Shouldn't an emulator be able to distinguish a peek from a read?
Yep. By request, the most recent update to FCEUX added support to examine this memory in the memory viewer. In the case of FCEUX, viewing memory (or registers) has no side effects, but modifying memory will have the same effect as the CPU writing that address.
Dwedit wrote:
Shouldn't an emulator be able to distinguish a peek from a read? A peek is what you would get if you would read that memory, but without any side effects from actually reading it.
Yes, it should, but Nintendulator does not because I never bothered to implement it; at this point it really isn't worth the effort, since I would either have to add a "isPeek" parameter to all read handlers (and incur a performance penalty during normal emulation) or make a separate copy of
every read handler which skips side effects (and require additional code for setting/getting them, making code maintenance a lot more annoying).