Is it by any chance possible to use a WRAM chip from a cart in the place of a CHR-ROM chip in an NROM board? It's just that I got a cart with WRAM that's not working and maybe I could turn it into VRAM? They are both 8k and... well, maybe it is a stupid Idea, maybe the pinouts are totally different or maybe it is not possible at all, but I just had to ask... Thanks for the help!
Certainly- both are just ordinary 6264 (read: 8kB static RAM) chips. If you're dropping it in an NROM board for CHR, though, you'll need to do a bit of rewiring (since the pinouts are different, and you'll need to connect the write signal).
Quietust wrote:
Certainly- both are just ordinary 6264 (read: 8kB static RAM) chips.
So they are indeed the same chip! That's cool!
Quietust wrote:
If you're dropping it in an NROM board for CHR, though, you'll need to do a bit of rewiring (since the pinouts are different, and you'll need to connect the write signal).
I see... if I change it to VRAM it will be a definitive change. Sadly I have only one NROM board. In case I ever decide to actually do this, is there info about this somewhere? The pinouts, mainly...
EDIT: I see now that the main page of nesdev has a document with the pinouts of the WRAM chip. I may try and play cool, pretending I know what I am doing, but I really doubt I can actually see everything that needs to be rewired. I'll try anyway, and if I have any doubts I'll ask here.
And Quietust, how would I go about connecting the write signal?
Hook the PPU /Write signal up to the VRAM's /WR pin. You'll have to totally desolder it from the PRG stuff of course. I've got an idea to make a WRAM-VRAM shared memory, but that's a whole other thing.
If you get a new RAM chip for any reason, it's usually cheaper/easier to find a 62256 (32kB).
Also, 6264 chips have both a positive and negative chip enable. That's fine as long as the positive CE is held at 5V.
Could someone please give me a crash course on the meaning of the pins? I can guess "A" stands for "address" and "D" stands for "data", but that's about it. Oh, and "GND" is "ground", right? I mean... I have no idea what are the "OE", "CE", "WE" things, and have no idea why a CHR chip has pins named "PRG". I appreciate the help.
"OE" = output enable
"CE" = chip enable
Virgule (/OE) or overline (O̅E̅): active low, meaning that the signal is asserted when at a logic value 0 (tied to GND).
As for "PRG", that's short for program. I guess it has something to do with the fact that some EPROMs and EEPROMs take a higher voltage to write than to read.
Thanks for the help. I'm planning on giving it a try this weekend, but I have one more question for now: the /WR pin is pin number 56 on the cart, right? I don't heve my cart here right now, but I know it lacks some pins by the middle, where pin 56 would be. So there is a possibility that this procedure can't be done to the Spy vs Spy cart?
I got another NROM game yesterday, though, it's Gyromite. This board is in much better shape than the Spy vs Spy one, and has all the pins, so I figured this would be my main NROM devcart, and Spy vs Spy was going to be used for experimental stuff (such as changing CHR-ROM for CHR-RAM). But if it lacks pin 56 I guess it is impossible then?
Thanks again for the help so far.
EDIT: OK, looking at the pinouts I think pin 56 (CHR /WR) of the cart has to be connected to pin 27 (/WE) on the 6264. Is that it? What else needs to be done? I think pin 26 on tthe 6264 needs some handling, but I'm really not sure of anything.
Having a cart wich is able to swich the same chip between WRAM and VRAM is a great idea, because you could get more pattern tables, while still having the advantages of CHRAM.
Wonder why Nintedo never did that.
It needs to change a lot on-board adress decoding. I'm not exacly sure how it works, so don't ask to me.
Bregalad wrote:
Having a cart wich is able to swich the same chip between WRAM and VRAM is a great idea, because you could get more pattern tables, while still having the advantages of CHRAM.
Wonder why Nintedo never did that.
The TQROM board has both CHR ROM and CHR RAM.
Quote:
It needs to change a lot on-board adress decoding.
The complexity of what happens when the CPU and PPU try to access CHR RAM at once is probably why no board maps CHR RAM into CPU space.
tepples wrote:
The TQROM board has both CHR ROM and CHR RAM.
That's not the point. I mean that effectivly be able to modify half of it by normal writes to $6000-$7fff when unused would be quite comfortable. Sorry if I confused people talking about advantages of CHROM or CHRRAM, that isn't what I really wanted to talk about.
What specific advantage would writes to $6000-$7FFF during vblank have over writes to $2006 and $2007 during vblank? Or do you want the writes to happen outside of vblank time?
tepples wrote:
What specific advantage would writes to $6000-$7FFF during vblank have over writes to $2006 and $2007 during vblank?
Random access to the CHR data would be cool. There are effects where pixels are calculated from previous pixels, wich are impossible to read during a sequential write to $2007. Or you'd be setting the address back and forth wich is really unproductive. A graphics (de)compression scheme could surelly benefit from random access to the pattern table.
Quote:
Or do you want the writes to happen outside of vblank time?
That'd also be very cool. As long as the tiles beeing updated were not beeing rendered/used at the same time. Very usefull to update part of the tileset for the next frame(s).
tokumaru wrote:
That'd also be very cool. As long as the tiles beeing updated were not beeing rendered/used at the same time. Very usefull to update part of the tileset for the next frame(s).
That would need to interfere two pattern tables. The first frame, the actual pattern table is swapped into PPU $0000-$1fff, and the programm can freely write data to $6000-$7fff during the frame. Then, on next VBlank, the mapper exchange both RAM segments, allowing the programm to change a lot of pattern table tiles every frame.
However, for non-dynamic tiles, you'll need to load them twice before using, once per swappable pattern table. That'd still be very cool.
tokumaru wrote:
Random access to the CHR data would be cool. There are effects where pixels are calculated from previous pixels, wich are impossible to read during a sequential write to $2007. Or you'd be setting the address back and forth wich is really unproductive.
Imagine doing a routine doing software mosaic effets on tiles.
With random acess, it would be pretty easy with some mask logic and shifts opperations. Just copy the color of a pixel on the pixel to it's right, to it's bottom and to it's bottomright in a gird of 2x2 pixels, then do the same for 3x3, 4x4, etc... to get bigger mosaics.
Without random acess, it need a large buffer where all images that changed their mosaic size should be copied to VRAM. But with such random acess, it would be much more abordable.