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

Re: an NROM to a cart with WRAM

Post by yogi » Tue Nov 26, 2013 2:10 am

lidnariq wrote: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.
lidnariq wrote: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.
lidnariq wrote: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
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 » Tue Nov 26, 2013 8:13 am

lidnariq wrote: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.
yogi wrote: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
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Tue Nov 26, 2013 1:17 pm

Hi tepples
tepples wrote:
lidnariq wrote: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.
tepples wrote:
yogi wrote: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
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Wed Nov 27, 2013 12:25 am

yogi wrote: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
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Wed Nov 27, 2013 5:36 am

lidnariq wrote:
yogi wrote: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
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Wed Nov 27, 2013 3:07 pm

yogi wrote: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
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Wed Nov 27, 2013 3:26 pm

lidnariq wrote:
yogi wrote: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.
lidnariq wrote:
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
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Sun Dec 01, 2013 4:14 pm

@ 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
Posts: 9508
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: an NROM to a cart with WRAM

Post by lidnariq » Sun Dec 01, 2013 5:42 pm

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
Posts: 133
Joined: Sun Nov 17, 2013 8:14 pm
Location: Bowie, Maryland

Re: an NROM to a cart with WRAM

Post by yogi » Sun Dec 01, 2013 6:44 pm

lidnariq wrote: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.
lidnariq wrote: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

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 Dec 02, 2013 6:22 am

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

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 Dec 02, 2013 1:25 pm

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.

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 Dec 02, 2013 5:36 pm

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.

Post Reply