It is currently Wed Sep 20, 2017 12:33 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Sat Jun 10, 2017 7:38 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 979
Location: Pennsylvania, USA
Are there any mappers which have an even smaller chr bank size than 1k? Or is that the smallest?


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 9:21 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7202
Location: Chexbres, VD, Switzerland
There's no technical limit, however I am not aware of a mapper that swaps smaller amounts than 1k. The same is valable for PRG-ROM, there is no technical limit but I do not know any mapper swapping banks smaller than 8k.


Top
 Profile  
 
PostPosted: Sat Jun 10, 2017 9:26 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5613
Location: Canada
Bregalad wrote:
I do not know any mapper swapping banks smaller than 8k.

Mapper 31 does 4k PRG banking, and it's based on NSF which requires it.

That's also why the PowerPak can't play NSFs over ~256k. Its PRG address control only goes down to 8k so it had to be worked around. Everdrive N8 can do it, though... but it doesn't have an NSF player. (You can't win!)


Top
 Profile  
 
PostPosted: Mon Jun 12, 2017 8:54 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
NovaSquirrel was desiring such a 512B CHR-banking mapper…but, as no other mapper had, the PowerPak doesn't interpose that address line, and can't do it.


Top
 Profile  
 
PostPosted: Mon Jun 12, 2017 12:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5613
Location: Canada
Myask wrote:
NovaSquirrel was desiring such a 512B CHR-banking mapper…but, as no other mapper had, the PowerPak doesn't interpose that address line, and can't do it.

Does it only fail to output that line to the CHR, or does it fail to receive it as input to the FPGA too? The NSF doubling trick could work otherwise (but cuts total CHR size in half to 256k).


Top
 Profile  
 
PostPosted: Mon Jun 12, 2017 1:05 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6155
Location: Seattle
PowerPak connects PPU A9 to CHR A9.

It does connect all lines from the cart connector to the FPGA.

(Must generate/relay: CHR A0,1,2,10,11,12,13,14,15,16,17,18)


Top
 Profile  
 
PostPosted: Mon Jun 12, 2017 2:15 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 936
Yeah, I meant it couldn't "properly" do it by banking over CHR_A9, because it's teed-in to that line, rather than (as for the lines lidnariq mentioned) having separate pins for the cart-edge and the [actually-RAM] ROMchip, which is what I meant by "interposing" [between them]. It's a bad habit f mine to use three words when a paragraph would do.

Don't you need to double the data on the chip to do that? [a custom loader could cause this to occur without inflating the ROM image, and hey, loader's part of the mapper file on PowerPak…]


Top
 Profile  
 
PostPosted: Mon Jun 12, 2017 2:58 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6155
Location: Seattle
Myask wrote:
Don't you need to double the data on the chip to do that? [a custom loader could cause this to occur without inflating the ROM image, and hey, loader's part of the mapper file on PowerPak…]
Yes... On the other hand, 256x512B = 128KiB anyway, so maybe that's ok?


Top
 Profile  
 
PostPosted: Tue Jun 13, 2017 1:02 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 210
Location: Fort Wayne, Indiana
rainwarrior wrote:
Does it only fail to output that line to the CHR, or does it fail to receive it as input to the FPGA too? The NSF doubling trick could work otherwise (but cuts total CHR size in half to 256k).

I wanted to use CHR RAM, which complicated things a lot, since you'd have to either do things where 512 byte banks can only be in even or odd slots, or where you'd have to write the RAM twice. I guess it could be a virtual CHR RAM+CHR ROM thing, where the small banks come from "ROM" but the 1KB or bigger banks come from RAM.


Top
 Profile  
 
PostPosted: Tue Jun 13, 2017 1:04 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6155
Location: Seattle
Depending on timing properties of the RAM used in the powerpak, you might be able to get away with changing the address in the middle of the write to split a single PPU write (which should take ≈186ns) into two (90ns each?)


Top
 Profile  
 
PostPosted: Tue Jun 13, 2017 2:00 pm 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 210
Location: Fort Wayne, Indiana
lidnariq wrote:
you might be able to get away with changing the address in the middle of the write to split a single PPU write

If you write to the first half of a 1KB bank, even if you change the bank mid-write, I don't think the FPGA can assert that it wants to write to the second half of that other 1KB bank.

The reason I wanted 512 byte banks in the first place was doing an enhanced version of the 1KB "1 player bank, 3 sprite banks" strategy where each of the bank slots provides access to the tiles for a particular animation frame of one of the entities on the screen, where instead of 3 independent entities you'd be able to have 6. There's probably other ways to approach that that'd be even better and get you more entities.


Top
 Profile  
 
PostPosted: Tue Jun 13, 2017 2:11 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5613
Location: Canada
NovaSquirrel wrote:
The reason I wanted 512 byte banks in the first place was doing an enhanced version of the 1KB "1 player bank, 3 sprite banks" strategy where each of the bank slots provides access to the tiles for a particular animation frame of one of the entities on the screen, where instead of 3 independent entities you'd be able to have 6. There's probably other ways to approach that that'd be even better and get you more entities.

Considering that it's CHR-RAM, if each character had 8 x 512 byte sprite pages, you could fit 6 characters into 3 x 1k banked regions just by loading all the permutations of pairs. 8 x 8 combinations is only 64k. 6 characters in pairs like that would only take 192k.

Kind of a trade of constraints on how many source pages you need vs. how many independent characters you want. If some of the characters use the same pages, you could reuse the same 1k pages in different 1k bank slots too?


Last edited by rainwarrior on Tue Jun 13, 2017 2:13 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Jun 13, 2017 2:13 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6155
Location: Seattle
... Right, without the FPGA being able to drive CHR A9 we can't make the data appear in both the lower and upper 512B half.

(the FPGA can change one of the addresses it does control in response to a divided copy of the 21MHz clock, not just in response to PPU A0..A13)


Top
 Profile  
 
PostPosted: Tue Jun 13, 2017 5:00 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18986
Location: NE Indiana, USA (NTSC)
rainwarrior wrote:
Considering that it's CHR-RAM, if each character had 8 x 512 byte sprite pages, you could fit 6 characters into 3 x 1k banked regions just by loading all the permutations of pairs. 8 x 8 combinations is only 64k. 6 characters in pairs like that would only take 192k.

Kind of a trade of constraints on how many source pages you need vs. how many independent characters you want. If some of the characters use the same pages, you could reuse the same 1k pages in different 1k bank slots too?

In The Curse of Possum Hollow, we ran into a problem with permutations of characters. The game uses MMC3 with 32 KiB CHR RAM, where the player sprite uses banks 16-23 in window 2 ($1000-$13FF), commonly used objects such as powerups and particles use bank 31 in window 5 ($1C00-$1FFF), and enemies can use banks 24-30 in window 3 ($1400-$17FF) or window 4 ($1800-$1BFF). If a particular sprite sheet is 1K or smaller, multiple actors using it can share a window. (Only players and bosses have a larger sprite sheet.) But if both window 3 and window 4 are in use, and the enemy does not share a sprite sheet with the enemies in window 3 or the enemies in window 4, it enters a queue where it waits to pop into existence until window 3 or window 4 is no longer in use. (This behavior can be seen in the pattern table viewer when the game is run in a debugging emulator.)

In order to have more than two types of enemy on screen at once, we had to combine enemies that commonly occur next to each other and have less than 1K of tile data (thirty-two 8x16-pixel tiles) between them into the same sprite sheet so that they can share a window. The initial plan was to do this combining at build time, assuming that these pairs of enemies that take up parts of the same 1K sprite sheet would always occur together. But later on, the level designer felt frustration in not being able to freely vary enemy placement due to window conflicts. At that point, it was too late to change the fact that combination is done at build time, not runtime, without unduly delaying the game's release for a revamp of the sprite system. So I made a tool that would read the enemy placement data from the source code, find places where too many enemies or enemies from too many different sprite sheets are placed near one another, and write the level filenames and coordinates of the places most likely to be painful. Some were false positives, such as enemies that enter and quickly leave the screen or "decoration" enemies that can wait to pop in until other enemies leave or are destroyed.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 7 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