an NROM to a cart with WRAM

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

an NROM to a cart with WRAM

Post by yogi » Sat Nov 23, 2013 11:01 am

Hi all. can some one point me to some docs or advise me. There is a homebrew, cajoNES, that is: 32K PRG ROM, 8K CHR ROM, so NROM right? The author, Neil Baldwin, also has a version that uses 8K WRAM for saves. I was checking out the iNES header in Nestopia and it lists the mapper as 0 and has Save memory enabled.
So my question is how does this translate to a real cart? Which mapper can you load an NROM onto without having to patch for banking? Is there a kind of extended NROM mapper?
Yogi

tepples
Posts: 22018
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: an NROM to a cart with WRAM

Post by tepples » Sat Nov 23, 2013 11:10 am

Family BASIC exemplifies mapper 0 with WRAM. It was originally distributed with 2K or 4K of WRAM, but the decoding would be the same for 8K, which is what emulators typically implement.

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Sat Nov 23, 2013 12:32 pm

OK, I did see that noted on the nrom page of the NESDEV wiki. I'm guessing that it being the only title, it would be VERY difficult to lay my hands on one for a donor (and more valuable to a collector).
So I was going through the SxROM page on the wiki, thinking:
!. That it might be possible to use a SNROM board. Rewire it, bypassing the MMC, in effect to create a NROM+BatBacked RAM cart.
2. Or if I leave the MMC and pad the PRG chip with the 32K bin and replace the CHR RAM with ROM?
Does any of this seem workable, or am I missing a big issue? And Yes, the simplest answer is 'PowerPak'; but I like hardware hacks.
Yogi

tepples
Posts: 22018
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: an NROM to a cart with WRAM

Post by tepples » Sat Nov 23, 2013 12:39 pm

What you can do is add the same circuit that Family BASIC uses to your NROM donor. Start by getting a 74HC20 and a 6264 or 62256 SRAM. I'd bet others can finish the explanation. If you can't do that, a mapper hack to SNROM is probably the best way to proceed, so long as you can find about 128 bytes of free space in $C000-$FFFF to insert code that sets up the MMC1 registers and copies 8K from ROM to RAM.

lidnariq
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Sat Nov 23, 2013 12:40 pm

For reference, a wonderful person reverse-engineered the PCB used by Family BASIC:
http://www43.tok2.com/home/cmpslv/Famic/Fambas.htm

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Sat Nov 23, 2013 1:13 pm

@ tepples Thank you very much! This is very much what I was looking for. For the moment I want to find a HW solution. Just getting started with NES software; not too different from Atari, aside from NES' memory mapping architecture (very different!) Had not considered the impact of the MMC in my question#2, and without looking at the source code don't know how $C0 page is handled.
@ lidnariq Thanks to you also, very good link, Thank the webgods for Google translate! Will be digging into it.
Thanks again for the input, seems very doable now, just some more reasearch!
Yogi

User avatar
qbradq
Posts: 951
Joined: Wed Oct 15, 2008 11:50 am

Re: an NROM to a cart with WRAM

Post by qbradq » Mon Nov 25, 2013 8:13 am

Yogi, do you want to run this particular homebrew with SRAM support on hardware, or are you looking for an easy-to-use development platform for the NES?

If the former, you can look into modifying the ROM to work with MMC1. In a nutshell, you would alter the reset routine to initialize the MMC1 and set up the expected banks, then jump to the original reset routine.

If the latter, INL's boards and programmer are all you need. You can order them pre-populated with WRAM and pre-loaded with a mapper of your choice.

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Mon Nov 25, 2013 11:46 am

Hi qbardq. ATM I was hoping to avoid patching the rom; the source is not released and I haven't approached Neil Baldwin (though he seems like a nice guy that would share). Also my skill level with NES programming is at the very bottom of the learning curve; well sort of, have been banging out 8bit firmware on different platforms over the years but the NES is new to me ;)
For me, a hardware/cart mod is far easier and a good learning exercise. After comparing eprom and ram pin outs, I plan to repurpose a SNROM board (it has footprints for almost all). Remove the MMC1, add a 74hc20 Ram decoder, replace the CHR ram with CHR rom and a little blue wire routing. 2-27c256s and a 74hc20. SNROM to NROM w/BBRam, simple right? (Ha Ha Ha <evil_ Laugh>, well we'll see)
I have ordered a kazzo/retro dumper and SXROM flash board from INL already, to run two other titles from Neil. So very happy to find INL's project; but for this case, the mod I plan on seems like a good starting point.
One point I could use some help with: PPU Horz vs Vert mirroring. In this case the code doesn't scroll the screen, so is there any difference between V or H if you aren't using scrolling? Or does this setting apply to the tiles that make up a single screen?
NROM boards have the H/V solder bridge pads and the MMC1 controls it on SxROM boards; from the pinouts I under how to jumper for one or the other, but don't know how to tell which, V or H, to setup.
Yogi

tepples
Posts: 22018
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: an NROM to a cart with WRAM

Post by tepples » Mon Nov 25, 2013 12:20 pm

The difference is that some non-scrolling games might depend on a particular mirroring for whatever reason. A couple of my games, for example, use a constant scroll value to center the display.
You can use an emulator to view the ROM image's header. But emulators tend to use "mirroring" terminology, while Nintendo cartridge boards use the opposite "arrangement" terminology.

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Mon Nov 25, 2013 12:45 pm

Doh! I'm such a noob! I had looked at the iNES header earlier, but didn't pay attention to the Mirroring. Nestopia shows Horz mirroring checked, so an NROM cart would have Vert bridged, yes?
Yogi

lidnariq
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Mon Nov 25, 2013 1:38 pm

I just looked inside the cajoNES(and +) ROM: it's actually only about 6KiB in size; almost all program. You could just program it onto an 8KiB PRG ROM. Similarly there's only 2KiB of CHR, although it'd require a little work to compress it below 4KiB.
It's also written to work (mostly?) correctly on an MMC1 board; it has a stub in both the first and last 16KiB halves that resets the MMC1 (although doesn't do anything more, such as initialize CHR banks)

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Mon Nov 25, 2013 7:20 pm

lidnariq wrote:I just looked inside the cajoNES(and +) ROM: it's actually only about 6KiB in size; almost all program. You could just program it onto an 8KiB PRG ROM. Similarly there's only 2KiB of CHR, although it'd require a little work to compress it below 4KiB.
When you say "... compress it below 4KiB." don't follow you. So you mean trying to fit the PRG and CHR in a 8K rom, there wouldn't be enough space? The only reason I mentioned 27C256 eproms is I have a stash stored away from way back when of my 8052 uC days.
Don't know how CHR data is structured on a MMC1 PRG rom too well. As I understand, CHR data is moved from the PRG rom onto the CHR ram at runtime. This is controlled by the kernel. Right so far? So the structure of the 'game' determines when new screen data is moved into CHR ram. All under the control of the 2A03?
Not that this is directly related to this case, but If you had say 30K of game kernel and 12K of CHR data, you would need at least 3 16k banks on the PRG rom? Would the CHR data be a contiguous block or distributed within the relevant kernel code? Or is the choice more of a style matter?
lidnariq wrote:It's also written to work (mostly?) correctly on an MMC1 board; it has a stub in both the first and last 16KiB halves that resets the MMC1 (although doesn't do anything more, such as initialize CHR banks)
So to do so, I would need to merge the CHR data into the PRG bin and include code to load to the CHR ram or rechip a SNROM board with PRG and CHR roms?
Sorry for all the questions and thanks for your help,
Yogi

lidnariq
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Mon Nov 25, 2013 8:31 pm

Sorry, my mistake for leaving too much implicit.

The NES has two entirely disjoint memory spaces: the CPU's and PPU's. The iNES dump format (.nes) stores the PRG ROM as a multiple of 16 KiB. When I looked at the actual data Neil provided, the first 16 KiB and final 10 KiB were almost all padding. So there's only 6 KiB of actual program code and data the CPU sees. This could have its padding removed by taking the 8172 bytes starting at byte 16400, and then appending the 16 bytes starting at byte 32768, for a total of 8KiB to be burned in an 28C64.

The NES can have either RAM or ROM connected to its video generator. Most early games used ROM, because it is simpler. CajoNES uses ROM, and if you look at it, it's 4 KiB of data, followed by 4 KiB of padding. (Additionally, those 4 KiB of data contain 2 KiB of padding inside it, but not in a way that is easy to remove). Then again, it's not exactly easy to find 27C32s or 27C16s any more, so it's not like the CHR optimization is all that worthwhile.

For games that use CHR RAM, the program will need to upload data to it before it can display anything.

Using MMC1 is orthogonal to the question of RAM or ROM—almost no "mapper chips" require one or the other.

Go ahead and use the two 27C256s. You might consider using an SJROM or SKROM donor instead. Since you don't want to modify the program yet, you can remove the CHRRAM and replace it with ROM.

Since the program is MMC1 compatible, you don't need to remove the MMC1. The MMC1 already provides the logic to enable save RAM at the right time. (That said, since you're using UVEPROMs, do you have an eraser in case something goes wrong?)

yogi
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Mon Nov 25, 2013 10:21 pm

lidnariq wrote:Sorry, my mistake for leaving too much implicit.

The NES has two entirely disjoint memory spaces: the CPU's and PPU's. The iNES dump format (.nes) stores the PRG ROM as a multiple of 16 KiB. When I looked at the actual data Neil provided, the first 16 KiB and final 10 KiB were almost all padding. So there's only 6 KiB of actual program code and data the CPU sees. This could have its padding removed by taking the 8172 bytes starting at byte 16400, and then appending the 16 bytes starting at byte 32768, for a total of 8KiB to be burned in an 28C64.
OK very clear.
lidnariq wrote:The NES can have either RAM or ROM connected to its video generator. Most early games used ROM, because it is simpler. CajoNES uses ROM, and if you look at it, it's 4 KiB of data, followed by 4 KiB of padding. (Additionally, those 4 KiB of data contain 2 KiB of padding inside it, but not in a way that is easy to remove). Then again, it's not exactly easy to find 27C32s or 27C16s any more, so it's not like the CHR optimization is all that worthwhile.
I know I read it somewhere, but can't recall; what is the max of the PPU's memory map, I.E. 8K addressable without bank-switching?
lidnariq wrote:For games that use CHR RAM, the program will need to upload data to it before it can display anything.

Using MMC1 is orthogonal to the question of RAM or ROM—almost no "mapper chips" require one or the other.
OK, so CHR ram is really a savings to commercial producers, only one mask PROM onto a generic board
lidnariq wrote:Go ahead and use the two 27C256s. You might consider using an SJROM or SKROM donor instead. Since you don't want to modify the program yet, you can remove the CHRRAM and replace it with ROM.

Since the program is MMC1 compatible, you don't need to remove the MMC1. The MMC1 already provides the logic to enable save RAM at the right time. (That said, since you're using UVEPROMs, do you have an eraser in case something goes wrong?)
After taking a closer look at the SJ/SKROM boards; thanks for the pointer. OK I see, the boards support larger CHR roms. They all have the same MMC, so it's the assignment of the available output bits on the MMC that dictate the usable rom sizes on the different boards. And of course how the code uses them. Cool.
As to my tool chain, yea I'm set. The UV box has been in a drawer mostly since I switched to flash PICs back around 2000. I replaced my old burner with a Williem 5c a couple years ago when I got more active with Atari 2600 stuff ( but then ended up getting a Harmony cart), the old commercial software wasn't supported past Win98.
Thanks so much for your advice, idnariq. Really only just started digging into the NES, and all the help here is speeding up the process!
Yogi

lidnariq
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Mon Nov 25, 2013 11:37 pm

yogi wrote: I know I read it somewhere, but can't recall; what is the max of the PPU's memory map, I.E. 8K addressable without bank-switching?
8 KiB of pattern tables (8x8 2bpp tiles), 4 KiB of name tables (screen layout), 28 bytes of palette memory, in that memory space.
The PPU actually has another disjoint memory space, 256 bytes just for sprites, but it's entirely internal.
yogi wrote:OK, so CHR ram is really a savings to commercial producers, only one mask PROM onto a generic board
I'm not even certain about that. RAMs and ROMs seem to be pretty comparable in cost. The big thing is that RAMs can dynamically update their contents, such as done by Color A Dinosaur or (most impressively) by Elite. On the other hand, ROMs can be told to change what's drawn on screen much more rapidly, such as all the animations in SMB2.

By the way, CajoNES+ only uses 2KiB of the save memory, that mapped from $7000 to $77FF. This is identical to the behavior Family BASIC v2.0. (Not that 2K RAMs are all that trivial to find, either)

I keep on having this feeling like I should be trying to encourage you to not use an ASIC'd donor board, but there aren't all that many good options and DIP stacking is goofy.

Post Reply