Using unused nametable RAM as a general RAM deposit?

As the title says, and generally speaking - is this viable, or a no-go?
I know it'd be slow and squeezed as you'd need to go through the PPU to get it, but anyway.
The automatic PPUADDR increase is at least something, and the PPUDATA register is read/write.
Are there any precedents to study?

As usual, I feel this is a "asking about A, but I should be asking about B" question.

How much RAM do you need?

Why not use $6000-7fff? WRAM.

What is the actual issue you are facing?

There's not really an "issue"- I'm trying to get a fuller understanding in order to map what i can actually do, if needed, and to be able to accurately choose a suitable mapper in regards to features and pricing.
Some sort of games, like previously discussed, may require relatively massive amounts of volatile data: Generated+persistent worlds, fully alterable/destructible worlds, and simulations (with generated, persistent objects), or a combination of said types.

The reason these types of games don't come aplenty on the NES is because developers stayed within conventions.

Two precedents:

• Games like Super Mario Bros., Vs. Super Mario Bros., and Milon's Secret Castle store some data in CHR ROM that wouldn't fit in PRG ROM.
• RacerMate Challenge II board has a lot of CHR RAM, 32K of it battery-backed.

AKA the XY problem of people forgetting to describe the goal that a step is intended to achieve. Sometimes one has to be vague about the goal out of confidentiality or humility, but a useful "vaguebook" or "subtweet" post at least includes a suggestion of a goal.


Extra component to buy ($), footprint on the PCB ($), and assemble (time, which is $).


It probably involves a board with a bunch of otherwise unused extra CHR RAM, such as UNROM 512 or GTROM. This appears to have become more common with self-flashability, as it's cheaper than adding a WRAM and a battery to the board.

Yes, these are the two candidates i'm looking at more closely currently.

”Inherent Smile” from this years’ compo stores quite a bit of data in chr-rom. That’s sort of the origin why i started looking into unused nt-ram when i realized this resource is there anyway with certain mappers. And for games not needing 4-screen mode as much as it may need ram for variables, that’s interesting considering the price of manufacture compared to wram additions, plus if fROM, a saving alternative to battery backing.

The problem with using VRAM as RAM is...

1. it's slow. You have to wait till v-blank or turn rendering off to access it.

2. It might cripple your ability to scroll, if you are using nametable VRAM.

3. It's non-standard to the official NES games. If you are doing something beyond what actual games did, why not just make a modern game?

I don't see any problems in using VRAM as general RAM, if the limited access is not a problem.


This is bullshit. If there was no innovation, every NES game ever would look like Balloon Fight, and there'd be no mappers using the cartridge port's signals in creative ways.

Also, there have been cases of NES games from back in the day using video memory for other purposes, such as SMB and some CNROM games storing miscellaneous data in CHR-ROM or battery-backed CHR-RAM being used to save games.

The only major problem with using PPU RAM for a generic store is that DPCM collides even worse with reads from the PPU than with the controllers.

I just mean...
If 10k of RAM isn't enough, then maybe NES isn't the best platform. SNES has standard 128k RAM, and you can still use mode zero if you REALLY want it to look like an NES game.

Some games read the Nametables contents for collision/game logic, so you could certainly use it for whatever you want. Is it really a good idea? That will depend on your specific situation. In general it's hard to see a reason to store random information in NameTables. If you had a non-scrolling game then that might work but in that case are you really going to be that short on RAM that an extra 1KB is going to help? Again maybe in your specific situation the answer is yes.

But that's literally not the starting position here.

The starting position is "So, we're using GTROM or UNROM512 or maybe even just a single-screen game without scrolling and there's extra RAM that we have no use for stored behind the PPU. Is there a reason we shouldn't make use of it?"

Maybe 10k is more than enough, but 2k isn't, and a little bit (maybe not so little in the case of GTROM) of limited access RAM that is already available is a better option than adding a whole new chip.


That's no fun. When you stumble on a system's limitations you don't immediately deem it unusable and move on to more powerful hardware, you first think of clever ways to make things work under the current setup. That's one of the most interesting aspects of retro programming, IMO.

Also, retro programmers often pick specific consoles for a reason (nostalgia, popularity, availability, cost, challenge, etc.), so it makes little sense to say "just pick another console" as soon as something appears slightly harder or unusual to code.

As you and I both wrote elsewhere, people who spend money on a Super NES Game Pak expect the graphics to look no less detailed than those of launch title Super Mario World. I doubt there is much interest in Super NES games that use only the increased RAM, not the increased graphical capability.

I would say, though it's not great for random access, or continual access, it's actually a very practical place for a battery backed save or perhaps data for a larger dynamic world that you can swap out during screen transitions.

If you're going to use CHR-RAM, the price difference between 8k and 32k SRAM is basically nothing, so at that point you have free 4-screen if you want it, and up to 20k of "inconvenient" storage, depending on how much mapper you want to dedicate to accessing it. Even without any CHR mapping there's still nearly 4k of extended nametable memory. Probably much better to battery back that than add a separate PRG-RAM chip.

(Sorry that this is a bit redundant, just it didn't seem like anyone had explicitly spelled this out in the thread yet.)


I disagree with this. It's not "conventions" its real economic problems, many of which don't apply to us now (like the price of 32k SRAM). Even if the hardware prices were comparable to now, there's still all the constraints that come with commercial development that make this entirely an unfair comparison.

If anything, I think many developers were chomping at the bit to do this kind of thing. It's what drove the development of things like the FDS or 64DD, which were repeatedly market failures. Even SimCity was developed and cancelled. They wanted to make these games, but really couldn't. This thing you are calling avoidance by "convention" was actually a problem many tried to solve and failed in that commercial environment.

Wrecking Balls was going to (and if I ever get out of this hole I've fallen into, eventually will) use battery-backed CHR-RAM to store custom board layouts. It already uses CHR-RAM anyway, the graphics are so simple the second nametable is unused, the board layouts are tiny and they only need to be accessed at the start of a round, when rendering is off to fill the nametable anyway.

My entry to this year's compo is a flick-screen game so I store all the maps in two unused CHR-ROM pages. In the worst case scenario, I'll be reading about 192 bytes of data (way less most of the time as there's some sort of RLE involved), and the impact is almost nil, as it is doing during screen transitions. So yes, it's something to consider. It saved me 16K in PRG-ROM (which was a monolithic, unbanked 32K)

I had this idea in mind when I added the 4 screen variant to UNROM512 which was used for Black Box Challenge, however I don't believe Roth used the PPU scratch RAM. I put an explanation at the end of the board section on the wiki. It has the convenience of a fixed 3.75KByte of ram at PPU $3000-3EFF.

As rainwarrior kind of brought up, this is becomes especially handy for flash saves where the minimum erase block is a 4KB sector of PRG-ROM. If you're minimizing save space to a single 4KB sector, you may need a sizable space to store a copy of contents while erasing. PPU-RAM may be your only viable option in that case. It could also be helpful to create a simple save file system while limiting flash erase/write wear. If the nonvolatile copy of save data/statistics was rather large and didn't fit in your 2KB WRAM budget, you could keep it in PPU-RAM instead. Then whenever the user selects the save feature, the single 4KB PRG-ROM save sector is erased, and PPU-RAM save data copied to flash. By only triggering flash erase/write when the user manually selects save it's a safe assumption you'll never approach the ~100,000 erase cycle endurance point.

It's somewhat of an aside, but related to storing CPU data in PPU memories. I've often considered, but never seen storing save data in CHR-ROM flash. It may be partially due to the fact that most homebrew target CHR-RAM mappers. But colordreams (mapper11), is the lowest cost CHR-ROM discrete mapper which grants access to all PRG-ROM & CHR-ROM's minimum size of 128KB in today's market. While remaining a single chip mapper it can be expanded to 512KB PRG-ROM (128KB CHR-ROM). The financial/hardware perk of flash saves in CHR-ROM is that no additional logic/chip is needed to have erase & write access, you simply connect PPU /RD & /WR to flash /OE & /WE and PPU A13 to /CE. In comparison flash saves in PRG-ROM will always require an extra logic gate to separate mapper writes from flash writes (NROM being the exception, but giving up 4KB of 32KB may be too costly). The software perk of saves in CHR-ROM is that the save routine is greatly simplified as the save routine can execute from PRG-ROM. In comparison PRG-ROM flash saves must have their save routines copied to RAM and execute from there since the PRG-ROM is not accessible during erase/write operations (and thus can't be executed from). Biggest problem with this is that no emulator currently supports it, but most boards using flash for CHR-ROM probably support it inherently, mine certainly do.

But yes there are many uses for storing CPU data in CHR memory if you can work within it's limitations. Racermate goes so far as to battery back CHR-RAM for save data likely because adding a battery to CHR-RAM is cheaper than adding PRG-RAM + battery. Even SMB was so tight on PRG-ROM space that they put some of the 6502 title screen code in CHR-ROM and copied it over to RAM for execution. I'm sure there are other historic examples of utilizing PPU memory solely for CPU rom/ram, but those are ones I'm aware of.

It used to be the case that flash was cheaper than SRAM, also, but more recent pricing for 32 KiB SRAM and the cheapest new 5V flash is more at parity. (Looking at octopart, it looks like RAM got cheaper more than flash got expensive?)

It's awkward, and doesn't have a predefined mapper for it, but some of the PRG bank bits could serve double duty as CHR bank bits, if there was really a need to exceed 128 KiB CHR.

(Also: oversize mapper 38 for 128K PRG + 512K CHR
edit: or a subset of one of the discrete logic multicart mappers (62,228,225) would also work well for "more flexible" oversize GNROM)

Doesn't have to? We can't buy new parallel flash smaller than 128 KiB anymore, and we don't have to tie A15 and A16 to a constant. Instead, we can tie A0 to A2 and A1 to A3 so that we can still send the required command sequence. This shrinks the sectors to 1/4, and reserving 1 KiB sector for saves is much closer to tolerable.

Ha ha the idea of wasting 96k to save 3k is a little bit amusing, but sure why not?


Big Bird's Hide and Speak also turned out to have sound data in CHR-ROM.

Well, you can't not waste 96k once you're putting NROM on the board anyway.

The amount of logic to divide the $8000-$FFFF range into a bankswitching region and a self-flash region is the same as to just map a bankswitching register below $8000 and generate /ROMOE. So there's a very small price region where the cost of a single 74'1g04 or BJT-based inverter might make more sense than GNROM plus some decoding logic.

At the moment yes, NOR flash market is in limited supply since last summer. It’s likely to recover at some point though..?


Ahh yeah that would be a good trick. It doesn’t really matter to the discussion, but doing that would effectively require a board dedicated to NROM. Because that wouldn’t be very compatible with most boards which target multiple discrete mappers with a single layout.

I don't think it was ever used, because it's extremely inconvenient to have RAM data only available during VBlank or forced VBlank. For most of game variable or arrays this is unacceptable. However if for some reason you need data that does not need access during a level but only between levels, then yes, it's a perfectly viable alternative to get an extra 1k of RAM.

You didn't mention CHR-RAM, but rainwarrior did, and if you don't use all the tiles, it's just as well a way to get extra RAM-which is only accessible during VBlank or forced VBlank.

You could do a buffer system where VRAM updates are used to write to or read that RAM portion, but honestly, that sounds terribly annoying to work with, and I don't see any situation where you need some extra RAM but the data can wait a frame or two before its retrieved. I might just be lacking imagination, though.

If you have a mapper capable of single-screen mirroring, such as mapper #1 or #7 you can even use the second-nametable-as-RAM and have scrolling in one or both axis.

Even if you are using both nametables and scrolling, technically a small part of the attribute table (upper nybble of the last 8 bytes) is unused (unless negative Y scrolling is used), so you could use it as an extra RAM. Because only the upper nybbles are free it doesn't sound practical, as you'd have to wait until VBlank to retrieve the data and do some and/or/bitshift operations in order to do so. Since this is a great total of 16x4 bits, equivalent of 8 bytes of data, I fail to see any situation where this much extra RAM makes any difference, but who knowns.