It is currently Mon Nov 12, 2018 11:58 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Feb 05, 2018 2:35 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 496
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)

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 8:28 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2096
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 9:17 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
infiniteneslives wrote:
It may be partially due to the fact that most homebrew target CHR-RAM mappers.
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?)

Quote:
While remaining a single chip mapper it can be expanded to 512KB PRG-ROM (128KB CHR-ROM).
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)

Quote:
Giving up 4KB of 32KB may be too costly
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.


Last edited by lidnariq on Mon Feb 05, 2018 10:54 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 9:32 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6947
Location: Canada
Ha ha the idea of wasting 96k to save 3k is a little bit amusing, but sure why not?

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

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


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 9:53 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
rainwarrior wrote:
Ha ha the idea of wasting 96k to save 3k is a little bit amusing, but sure why not?
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.


Top
 Profile  
 
PostPosted: Mon Feb 05, 2018 10:44 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2096
Location: WhereverIparkIt, USA
lidnariq wrote:
(Looking at octopart, it looks like RAM got cheaper more than flash got expensive?)
At the moment yes, NOR flash market is in limited supply since last summer. It’s likely to recover at some point though..?

Quote:
Quote:
Giving up 4KB of 32KB may be too costly
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.

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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Tue Feb 06, 2018 1:23 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7563
Location: Chexbres, VD, Switzerland
FrankenGraphics wrote:
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?

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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot], pubby and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group