I've seen that exact image before; you get it if you don't properly give uncharted waters its 16KiB of SRAM. It should work with 64KiB though? Never tried it, but it asks for prg ram "banks" %001 and %101.Anes wrote:I did one thing: i "marged" with my mapping engine.... i mean i used SwapPrg4K() to swap prg-ram.
UW Works (with some graphics glitches):
and BK of Ancient China now looks good.
The thing is i have a 64kb that's in the mapper... if i knew the prg-ram size would be prominent, but the wiki says that byte "8" should indicate that and roms out there have only "0". But, but it says that emulators even don't use this byte.
What do i do?
MMC5 problems...
Moderator: Moderators
Re: MMC5 problems...
Re: MMC5 problems...
I recommend always giving it 64K RAM if the NES 2.0 header is not present. (Disch recommends the same thing.)
[url=gopher://zzo38computer.org/].[/url]
Re: MMC5 problems...
I give up. I don't know what to do with this "extra 64K" and prg-ram swapping.
I have some questions:
Is prg-rom mapped to prg-ram?
How do you implement in your emus? Maybe a quick tutorial would help me... if im asking to much it's ok forget it.
I have some questions:
Is prg-rom mapped to prg-ram?
How do you implement in your emus? Maybe a quick tutorial would help me... if im asking to much it's ok forget it.
ANes
Re: MMC5 problems...
I'm not sure what that's supposed to mean - PRG ROM is what you load from the .NES file (and is read-only), while PRG RAM is generally what you load from the .SAV file (though for some games it isn't battery-backed and thus gets cleared when you power off the console). Both can be mapped to the CPU's address space, and they contain distinct data.Anes wrote:Is prg-rom mapped to prg-ram?
In my emulator, the CPU address space is divided into 4KB chunks, each having a pair of function pointers for reading/writing it (which can be overridden for memory-mapped registers) plus a data pointer and a pair of booleans indicating whether it's readable or writable (used only by the default read/write functions in order to handle read+write RAM, read-only ROM, and unreadable "open bus"). When I want to map PRG ROM, I set the pointer to point at the desired PRG ROM bank, set "readable", and clear "writable", and to map PRG RAM, I set the pointer to point at the desired PRG RAM bank and set "readable" and "writable". All of this is hidden behind an interface, so I can just say "map 16KB of PRG ROM at $8000 using bank 7" and it'll set $8000-$BFFF to contain 4KB banks 28-31.Anes wrote:How do you implement in your emus?
I do the same for the PPU address space, except there I use 1KB banks and also have 3 types of memory that can be mapped (CHR ROM, CHR RAM, and Nametable RAM).
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: MMC5 problems...
ROM and RAM are separate chips. You swap them both the same way.
The thing that's a little tricky with RAM is that it needs to be mirrored appropriately. IE, if the same page gets swapped into both $6000 and $8000... then those banks basically are mirrors of each other. Writes to one will be visible to another and vice versa.
Also the written values persist even when the page is swapped out. So if you swap RAM page 0 in... write to it... then swap in some ROM... then later you swap the RAM page back in... your previous writes will still be there.
This should be very easy to implement in any setup. If you have a situation where you use an array of pointers to do PRG swapping, it's as simple as pointing to a separate RAM buffer instead of your ROM buffer:
The only other thing you have to do is make sure that RAM is writable when swapped into $8000-DFFF. But be sure to also make ROM not writable when its swapped into that same area.
The thing that's a little tricky with RAM is that it needs to be mirrored appropriately. IE, if the same page gets swapped into both $6000 and $8000... then those banks basically are mirrors of each other. Writes to one will be visible to another and vice versa.
Also the written values persist even when the page is swapped out. So if you swap RAM page 0 in... write to it... then swap in some ROM... then later you swap the RAM page back in... your previous writes will still be there.
This should be very easy to implement in any setup. If you have a situation where you use an array of pointers to do PRG swapping, it's as simple as pointing to a separate RAM buffer instead of your ROM buffer:
Code: Select all
u8 ROM[0x40000]; // or however much ROM the game has
u8 RAM[0x10000]; // 64K of RAM
u8* prg[0x10]; // 16 pointers, one for each 4K page
// ie... if you want to swap $E000 to the last 8K of PRG-ROM:
prg[0xE] = &ROM[0x3E000];
prg[0xF] = &ROM[0x3F000];
// to read whatever is swapped into $E345:
u8 val = prg[0xE][0x345];
//
// RAM is the same thing. Just swap in the RAM buffer instead of the ROM buffer:
//
// swap in RAM page 0 at $C000-DFFF:
prg[0xC] = &RAM[0x00000];
prg[0xD] = &RAM[0x01000];
// swap in RAM page 2 at $A000-BFFF (8k pages):
prg[0xA] = &RAM[0x04000];
prg[0xB] = &RAM[0x05000];
// etc
