Upgrading SNES VRAM to 128 KiB

So I'd like to go ahead and install 128 KiB of VRAM in one of my test units (got the idea from this thread).


So if I understand correctly, this is how I would proceed:

• Desolder both original VRAM chips
• Solder an IS6*C1024AL-*K* SRAM onto the footprint of (any?) one of the two original chips with the proper alignment, leaving pins 1, 2, 31, and 32 floating (for running wires to other places later on)

As for the replacement chip, the IS61C1024AL variant should be fine for this purpose, but what about the -*K* part? I only seem to find the -12JLI type on eBay (for a reasonable price, that is), would that work as well?

Also, according to the datasheet, pin 1 is NC and 2 is A16.


Now, despite me being hopeless at understanding the AXX/DXX hardware stuff (believe me, I've tried hard), it does seem odd to me to connect A15 not to PPU1 VA15 but to Vcc, and instead NC/A16 to PPU1 VA15. @lidnariq, not meaning to question your design, but can you elaborate more on why this should work (and esp. why SRAM pin 1 needs to be tied to the PPU instead of being left floating)?

Also, would it be possible to maintain full software compatibilty by adding a two-way switch instead of a straight wire between PPU1 VA15 and whatever SRAM pins? If so, how would I need to wire the switch? (My guess is to tie the common terminal of the switch to PPU1 VA15 and the two other terminals to the SRAM pins and Vcc, respectively.)

Would love to try this out, so thanks for any further tips and hints.

Unused address lines should be connected to VCC or GND.

It doesn't matter what order the address lines are connected in, as long as all of them are connected.

The NC pin doesn't need to be connected to anything.

The RAM has two more address lines (A15 and A16), but you only need one of them. This means one will go to PPU1 VA15, and the other will go to VCC or GND. A15 happens to be right next to VCC, which makes it very convenient if A15 is connected to VCC.


It is possible, as far as I know. The common terminal should go to the SRAM address pin, and the other two will go to (read: switch between) PPU1 VA15 and either VCC or GND. I don't know if there's anything you'd need to do to prevent interference.

Specifically for the ISSI RAMs:

Unfortunately, the "K" part is what specifies that it's a 400thou SOJ part. I don't think any other parts are particularly compatible footprint-wise...

"Q" specifies it's a 445thou SOP part, which is clearly too wide at least on my SNES. The footprints on my SNES (for a standard 330 thou 28-pin SRAM) go from ≈400 thou to ≈520 thou; the legs on 445 thou SOP won't reach the PCB underneath until 490thou, which is uncomfortably tight. (For a visual aid, this is the difference on the Yoshi's Island SFX RAM upgrade)

"J" would specify it's a 300thou SOJ part. That's conspicuously too narrow, but you may be able to bend out the J-shaped legs far enough to reach the solder pads.

Digikey implies several other companies have parts that should be equally compatible:


For volatile RAMs (i.e. the kind that lose their contents when power is removed), the address lines are entirely arbitrary. You could hook them up in any order, and as long as there's a 1-to-1 mapping it'll still hold the same amount of data. (It doesn't matter whether the address line is numbered "0" or "52" or "bob"; each one still doubles the storage capacity relative to not including it.)

The reason I suggested soldering pins 32,31 to +Vcc and 1,2 to PPU1 VA15 is that it should be mechanically easier. (Nothing more, nothing less.)

Pin 1 could be left floating, if that'd be easier than soldering a wire to both pins 1 and 2. (Pin 1 doesn't need to be soldered to Vcc)

Yes:
Close, slightly backwards:

Common terminal should go to the SRAM pin; the two options should go to PPU1 VA15 and ... your choice of almost any other signal. Vcc, ground, VA14 would be fine.

> Also, would it be possible to maintain full software compatibilty by adding a two-way switch instead of a straight wire between PPU1 VA15 and whatever SRAM pins?

As an alternative idea by Cydrak, use one of the unused IObit lines (0-5) from the S-CPU. Then to enable 128KiB VRAM, simply clear said bit. I'm not sure which ones are exposed, but I know that some of them are.

If there's a game that both clears IObit completely *and* uses VRAMADDR incorrectly, then you're very unlucky >_<

Oh, I failed to explicitly reply to this. Two new RAMs to replace the two existing ones, onto both footprints.

Thanks for all the info, guys!

I was going to ask a couple questions about the software side of things, but this totally kills the whole idea IMHO:


So we'd need 2 * 128 KiB = 256 KiB of new hardware, of which we'd only use half. What a waste. Not worth it, if you ask me.

But maybe this thread is useful to anyone still feeling like trying this out.

How hard would it be to add a mapper to VRAM?

I mean, they don't manufacture 64 KiB SRAMs at all, apparently. Hence the waste of half.

You could also buy two extra 62'256s and somehow stack them on top of the existing ones. The SRAM /CEs are currently permanently grounded, so that could easily be used to switch between RAMs.

If you really wanted to not waste half the RAM, you could use a single 64 Ki x 16 bit RAM instead, but the soldering then becomes a PITA, and you break mode 7.

But when I look at the prices on digikey in the US, the cheapest 5V SRAM right now is the 32 Ki x 8 bit ISSI IS62C256AL, at 1.13USD/@10, in any choice of package. The cheapest >32 KiB RAM is the 128KiB TSOP IS62C1024AL*Q*, at 1.58USD/@10.

Actually, that might be an "obvious" solution here: use one of the unloved IObits on the CPU to bankswitch between two halves. Just rather than tying Vcc to RAM A15, connect one of the IObits instead.

If you were so inclined, you could even extend this to four banks by using two 256 KiB RAMs instead, the largest you can get a 400thou 32-SOJ.

So how does the SNES hardware determine when to write to which of the two stock VRAM chips? IOW, if we had just one 128 KiB chip on hand as a replacement, how/why is it we can't get away using only that?

As far as I can tell, it reads both chips at once but can write to only one of them. It chooses whether to write to the even chip or the odd chip based on bit 0 of the B bus. Bit 0 is clear during $2118 access and set during $2119 access. Does this 16-bit memory support 68000-style writes to only the bottom half or top half of a 16-bit word?

A 16-bit memory would break background rendering in mode 7, as it relies on driving separate addresses to the even and odd chips.

There's two address buses and two data buses and separate "do the write" control signals (named VAWR and VBWR in the redrawn schematic).

The only thing the two RAMs share is the "do the read" control signal (VRD), A14, and the (currently unused) A15.

Normally, the SNES PPU accesses the two separate 32 Ki x 8 bit RAMs as though they were a single 32 Ki x 16 bit RAM. And this is true at all times ... that are not mode 7.

Mode 7 uses the two address buses independently; one is used just to fetch the tilemap, the other is used just to fetch the pixels.

If you're saying "drat, I already bought exactly one, can I make lemonade out of this lemon?"

Uh... I don't see an obvious way. I'm sorry.

You can't remove both 32 KiB RAMs and replace only one... because then half the data bus won't have anything attached to it, and it'll just display random stuff. (Like if the red cable were broken in your monitor)

You can't remove just one RAM and replace it, because then your memory map will have one half repeating top-and-bottom and the other half will be fully present.

⇦ ⇩ ⇧ ⇨
Let's play some DDR.

Whether one 8-bit RAM can do the job of two depends on how fast the RAM is and how fast the PPU expects it to be. Look at the 8-bit VRAM in the Genesis for example: the VDP makes two 8-bit accesses to the same chip per pixel, compared to the S-PPU's one 8-bit access to each chip per pixel.

Luckily, no. I wasn't going to buy any parts at all before I'd brought up some software (i.e., programming) concerns I had.

Again, thanks for explaining all this stuff!