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?

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.

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

dougeff wrote:

What is the actual issue you are facing?

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.

It probably involves a board with a bunch of otherwise unused extra CHR RAM, such as UNROM 512 or GTROM.

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.

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

dougeff wrote:

3. It's non-standard to the official NES games.

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.

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.

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.

Quote:

SNES has standard 128k RAM, and you can still use mode zero if you REALLY want it to look like an NES game.

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.

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.

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.)

FrankenGraphics wrote:

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

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.

Who is online

Users browsing this forum: No registered users and 5 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum