an NROM to a cart with WRAM

[yogi]

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.

I see your point about the ram's flexibility and cost, I was only thinking about inventory, one maskPROM per title rather then two.

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)

As I understand from Neil's release docs, though the save's memory requirements are low he is 'reserving' up to the 8K for something he has in mind. So I'm thinking at some point a '++' version may be released. Fingers crossed.

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.

Yea, I feel a little bit guilty sometimes; but if I hadn't bought the cart from the thrift store, it wouldn't have sold and would have ended in the landfill. (How's that for a rationalization).
I had thought about adding a outboard battery backed ram board to a RetroPak NROM but I could only see this as a lot of extra work for a one-off. If Retrousb still carried the MMC1 boards, I would have gone with that. As it stands now i'm sure I can get this cart together with parts on hand, so the budget wins out
Yogi

[tepples]

Go ahead and use the two 27C256s. You might consider using an SJROM or SKROM donor instead.

An SNROM donor may work as well; Morita Shogi, for instance, uses it with an 8K CHR ROM.

OK, so CHR ram is really a savings to commercial producers, only one mask PROM onto a generic board

Expanding on what lidnariq wrote: CHR RAM allows for effects you just can't do with CHR ROM, such as drawing arbitrary shapes in the playfield (Qix, Videomation, Color a Dinosaur, Elite) or compositing at boundaries smaller than a tile (Solstice, Hatris, Cocoron, Battletoads, or any game using text in a proportional font like my current project) or even just ultra-fine-grained bank switching (again Battletoads). See also advantages and applications of CHR RAM.

[yogi]

Hi tepples

Go ahead and use the two 27C256s. You might consider using an SJROM or SKROM donor instead.

An SNROM donor may work as well; Morita Shogi, for instance, uses it with an 8K CHR ROM.

Yes. After comparing the SNROM's CHR Ram footprint to a RetroPak with NROM configured, I'm sure that a 27c256 should drop-in with only one question mark: Pin 27, A14 on the rom and /W on the ram. The retroPak pulls this high whereas the SNROM cart connects it to CHR /W. So in this case, I think /W should stay at a high with the PPU only doing reads from the CHR memory, but it is a simple matter to cut the trace and tie it high. Of course the 8K bin needs to be mirrored through out the 32K of the '256.

OK, so CHR ram is really a savings to commercial producers, only one mask PROM onto a generic board

Expanding on what lidnariq wrote: CHR RAM allows for effects you just can't do with CHR ROM, such as drawing arbitrary shapes in the playfield (Qix, Videomation, Color a Dinosaur, Elite) or compositing at boundaries smaller than a tile (Solstice, Hatris, Cocoron, Battletoads, or any game using text in a proportional font like my current project) or even just ultra-fine-grained bank switching (again Battletoads). See also advantages and applications of CHR RAM.

Wow, I had never considered these advanced techniques. My mind set is/was too locked up in the Atari memory model. One of the biggest things I have to remember is: the PPU is a true co-processor, which is quite different to Atari's approach with Antic/Gita's DMA access to a single bus at the expense of CPU cycles. Sega's SMS seems to borrow a bit from Nintendo's approach but is less flexible. All I can say is RESPECT.
Yogi

[lidnariq]

Yes. After comparing the SNROM's CHR Ram footprint to a RetroPak with NROM configured, I'm sure that a 27c256 should drop-in with only one question mark: Pin 27, A14 on the rom and /W on the ram. The retroPak pulls this high whereas the SNROM cart connects it to CHR /W. So in this case, I think /W should stay at a high with the PPU only doing reads from the CHR memory, but it is a simple matter to cut the trace and tie it high. Of course the 8K bin needs to be mirrored through out the 32K of the '256.

The 27C256 connects A14 to that pin instead, no? I don't think anything bad would happen—it'll effectively be equivalent to tying that pin high. I can't tell if pin 1 is floating, though.

Alternatively, I could hack up a simple modified version that would work correctly with SNROM's CHRRAM, and would upload the 4K of data I was talking about earlier to that CHRRAM, if you'd rather.

[yogi]

Yes. After comparing the SNROM's CHR Ram footprint to a RetroPak with NROM configured, I'm sure that a 27c256 should drop-in with only one question mark: Pin 27, A14 on the rom and /W on the ram. The retroPak pulls this high whereas the SNROM cart connects it to CHR /W. So in this case, I think /W should stay at a high with the PPU only doing reads from the CHR memory, but it is a simple matter to cut the trace and tie it high. Of course the 8K bin needs to be mirrored through out the 32K of the '256.

The 27C256 connects A14 to that pin instead, no? I don't think anything bad would happen—it'll effectively be equivalent to tying that pin high. I can't tell if pin 1 is floating, though.

Alternatively, I could hack up a simple modified version that would work correctly with SNROM's CHRRAM, and would upload the 4K of data I was talking about earlier to that CHRRAM, if you'd rather.

On this SNROM-05 board pin 1 is tied high, so its good. Looking closer, A14 will always be high during an access, seeing how the '256's /OE is tied to the PPU's /R, I'm assuming that /R and /W are exclusives. /R*/A13=CHR rom Selected with W*/A13*(A12:A0=any state)
Very kind of you to port it to SNROM it would be very convenient. I already have this board halfway converted, all the de-soldering done and a net list of jumpers, but I can see that it would be a lot easier for users to only replace the PRG rom or just get one of INL's boards. ATM I have a socketed SNROM board & 27c010 already, so I can test your port. With your permission, I'd like to pass your port along to Neil so he can host it if he likes.
Yogi

[lidnariq]

I'm assuming that /R and /W are exclusives. /R*/A13=CHR rom Selected with W*/A13*(A12:A0=any state)

Just the same as the 8051, yes.

With your permission, I'd like to pass your port along to Neil so he can host it if he likes.

I'll send it in PM. I don't want it distributed unless he's ok with it.

[yogi]

I'm assuming that /R and /W are exclusives. /R*/A13=CHR rom Selected with W*/A13*(A12:A0=any state)

Just the same as the 8051, yes.

Yes; it's been quite a few years since I messed with them 12 clocks per instruction cycle, those were the days.

With your permission, I'd like to pass your port along to Neil so he can host it if he likes.

I'll send it in PM. I don't want it distributed unless he's ok with it.

OK, thanks much! I'll reach out to Neil and see what he wants to do.
Yogi

[yogi]

@ lidnariq Thanks for the patched .nes! Works great! 8x padded to a 27c010, popped it in my SNROM devCart and 'tested' for hours! \o/
The SNROM patch is the easiest route for a cajoNES+ cart. Although I intend to finish the (S)NROM cart mod I started, it makes far more sense to patch the code or just code for a SNROM in the first place. There's allot more soldering and you have to build the WRAM controller, so it's not the easiest route but might be useful to someone(?); If you wanted to avoid mapping code but also wanted save data or you patched a NROM game to add saves. Wouldn't be the first time I built a useless project
Yogi

[lidnariq]

One thing that would be neat, but definitely wants the original source to work with, would be making a CHRless version.
What's nice about that is that you don't need to replace the CHR (only remove/disable it); instead it just cleverly repurposes the memory provided by the NES itself, because the graphics are simple enough that they can be redrawn to fit into 64 unique tiles.

On the downside, it won't work on every famiclone. But for everywhere it does work, it basically halves production cost and effort.

[yogi]

One thing that would be neat, but definitely wants the original source to work with, would be making a CHRless version.
What's nice about that is that you don't need to replace the CHR (only remove/disable it); instead it just cleverly repurposes the memory provided by the NES itself, because the graphics are simple enough that they can be redrawn to fit into 64 unique tiles.

That's an interesting idea.
Just ran across a web page the other day (didn't bookmark it) where a person wired up a bare EEPROM strait to the PGM bus , bypassing the 72pin connector. The setup had no CHR memory and relied on the 2k of VRAM; so the graphics were messed up due to the small storage, but as a proof of concept he was happy.

On the downside, it won't work on every famiclone. But for everywhere it does work, it basically halves production cost and effort.

Could make for a very simple cart if you're programming/designing it from the ground up.
I guess this flexibility is what makes the NES so great!
Yogi

[qbradq]

Unfortunately it doesn't work on most of the clone systems

[lidnariq]

I was under the impression that the clones were actually pretty random as to whether they paid attention to CIRAM/CE ? That's annoying, though.

[qbradq]

I say "most" because the clones that are the most readily available as a stand-alone system (at least where I live) all seem to be based off the same NOAC which ignores this signal.