It is currently Wed Oct 18, 2017 8:50 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Fri Mar 03, 2006 4:04 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
What is the best way to handle a bankswitching strategy ? I've myself always think that 16kb was the best, but I wonder what other people thinks ?
Is the best one 32kb bank, two 16kb bank, two 8kb banks and one 16kb, or four 8kb banks ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 9:58 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1389
If you're going to use DPCM extensively, then you'll need part of $C000-$FFFF switchable. Generally, though, you'll also want the upper PRG block to be fixed to the last bank to simplify dealing with interrupts.

The MMC3 happens to have a very convenient setup, where you have one switchable bank at $A000-$BFFF and an additional switchable bank which you can place at either $8000-$9FFF (to effectively give you a 16KB switchable bank at $8000-$BFFF) or at $C000-$DFFF (to allow the DPCM space to be banked). It's no wonder that the MMC3 was one of the most popular mappers used in USA games - it was reasonably simple (a 44-pin chip) but exceptionally versatile as well.

_________________
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 10:03 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
Effectively, DPCM samples can only be played from $c000-$ffff, so a MMC3 is needed to bankswitch them. However, I was asking in general, without using DPCM bankswitching.
Has two 8kb banks in $8000-$bfff any advantage on a single 16kb bank ? It effectively makes you able to have two different bankswitchable data appart of the 16kb hardwired data at $c000-$ffff. But has this any significant advantage ?
And is 32kb bankswitching good in any way other than simplify cartridge logic ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 11:48 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3943
Adding a switchable ram/rom bank to 6000-7FFF is always nice. Sunsoft had the right idea.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 1:34 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
If you have two interdependent data tables, such as compressed data and the decompression dictionary, that might be easier with two independent 8 KB banks unless you want to repeat the dictionary in each bank that has data or you want to put the dictionary in the fixed bank. Example of such would be a map (compressed data) and the metatile table (dictionary).


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 1:38 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
Yeah, I think I see what you mean, tepples. A simple programm that reads bankswitched stuff can easily fit in the fixed bank, but a programm that decompress something is usually large because it needs large tables/dictionaries, and it would be better to bankswitch it in an auxiliary space.
On another way, the Game Boy Color switches 16kb banks and have an hardwired 16kb bank just like the standard UNROM configuration. Many GBC games were much more modern and responsive than NES games, so it seems not to be a bad option.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 2:00 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
Yeah, I think I see what you mean, tepples. A simple programm that reads bankswitched stuff can easily fit in the fixed bank, but a programm that decompress something is usually large because it needs large tables/dictionaries, and it would be better to bankswitch it in an auxiliary space.
On another way, the Game Boy Color switches 16kb banks and have an hardwired 16kb bank just like the standard UNROM configuration.

But then the GBC has a sh*tload more RAM than the NES and most mappers provide, namely 32 KB CPU RAM (four banks of 8 KB) and 16 KB of VRAM (two banks of 8 KB). With that much memory, it can copy the dictionary from one bank to RAM, switch to the bank with the map, and then decompress using that.

Quote:
Many GBC games were much more modern and responsive than NES games, so it seems not to be a bad option.

The perceived GBC advantage may be a function of one or more the following:
  • GBC video has a sh*tload of hblank time into which to fit writes to VRAM.
  • GBC video is only 160x144 out of a 256x256 single-screen-mirrored plane, meaning that there's a lot of offscreen space in each nametable, so there isn't as much to worry about with effects at the seam.
  • The GBC video model resembles MMC5 ExGrafix with CHR RAM, so there's little need for monkeying around with bitwise operations on attribute tables.
  • The Game Boy has a hardware "window" to a second nametable and a scanline interrupt that resembles that of MMC5, allowing for versatile splits.
  • The GBC CPU is roughly twice as fast as the NES CPU. (An 8 MHz Z80 is roughly as powerful as a 4 MHz 6502.)
  • Updating palettes in hblank is easy, giving some programs almost Super NES-like backgrounds.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 2:21 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
tepples wrote:
But then the GBC has a sh*tload more RAM than the NES and most mappers provide, namely 32 KB CPU RAM (four banks of 8 KB) and 16 KB of VRAM (two banks of 8 KB). With that much memory, it can copy the dictionary from one bank to RAM, switch to the bank with the map, and then decompress using that.

That'd typically be thinkable with a RPG using SRAM at $6000-$7fff. Also, it would allow dynamic tables and dictionnaries, possibly adding more depht. Tough, most of the SRAM space should be left for un-compressed maps and gamaplay variables that may be saved.

Quote:
The perceived GBC advantage may be a function of one or more the following:
  • GBC video has a sh*tload of hblank time into which to fit writes to VRAM.
  • GBC video is only 160x144 out of a 256x256 single-screen-mirrored plane, meaning that there's a lot of offscreen space in each nametable, so there isn't as much to worry about with effects at the seam.
  • The GBC video model resembles MMC5 ExGrafix with CHR RAM, so there's little need for monkeying around with bitwise operations on attribute tables.
  • The Game Boy has a hardware "window" to a second nametable and a scanline interrupt that resembles that of MMC5, allowing for versatile splits.
  • The GBC CPU is roughly twice as fast as the NES CPU. (An 8 MHz Z80 is roughly as powerful as a 4 MHz 6502.)
  • Updating palettes in hblank is easy, giving some programs almost Super NES-like backgrounds.


Wow ! I didn't know all of theese. I asked myself many many times why GBC games have so, so much better graphics than NES games with the same bitdepht.
I think GBC also can hanldle the sprite priority bit on background map instead of just spries as the NES does, so this makes layering much easier to handle, isn't it ?
Unfortunately there is much less doccuments available on Game Boy (not Advance) hardware for an unknow reason. There is general purpose doccuments, but none of theese goes in detail.
Also, lot of GBC games (the ones wich aren't in a transparent cartcase) are backward compatible with older monochrome Game Boys, and so they have less VRAM and stuff.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 03, 2006 4:41 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
I think GBC also can hanldle the sprite priority bit on background map instead of just spries as the NES does, so this makes layering much easier to handle, isn't it ?

Yes. The GBC has more layers than even a GBA based emulator can handle. From top to bottom, the following must be drawn:
  1. Window tiles at priority -1
  2. Playfield tiles at priority -1
  3. Sprites at priority 0
  4. Window tiles at priority 0
  5. Playfield tiles at priority 0
  6. Sprites at priority 1
  7. Window background colors
  8. Playfield background colors (imagine if $3F04, $3F08, and $3F0C on the NES actually did something)
Quote:
Also, lot of GBC games (the ones wich aren't in a transparent cartcase) are backward compatible with older monochrome Game Boys, and so they have less VRAM and stuff.

Nintendo Power says that some of those have two completely separate game engines: one optimized for GB and one optimized for GBC.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 04, 2006 10:49 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7230
Location: Chexbres, VD, Switzerland
Two separable game engine on the same cartridge ? That's pretty odd. Additionally, Nintendo would prefer having more people buying the new GBC than have people stuck with their old game boys. I foud that kinda strange. Now, the GBA plays the older games as if they were played on a GBC, regardless of the cartridge itself.
The windows is a separate layer for text windows that cannot be scrolled, right ? That's a really good feature. It's a real shame the NES doesn't have this, so programmers have to "monkey" (to use your therms) doing mid-frame PPU writes, sprite zero hit, timed code, etc...

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 04, 2006 11:36 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
Two separable game engine on the same cartridge ? That's pretty odd.

See Space Invaders, which had separate engines for Game Boy (GBZ80) and Super NES (65C816 + SPC700).

Quote:
Additionally, Nintendo would prefer having more people buying the new GBC than have people stuck with their old game boys.

Console makers who use the lockout chip business model break even on console hardware and make money on software.

Quote:
The windows is a separate layer for text windows that cannot be scrolled, right ?

Or for a status bar, or an MMC5-like vertical split (see Tetris Attack), etc.

Quote:
That's a really good feature. It's a real shame the NES doesn't have this, so programmers have to "monkey" (to use your therms) doing mid-frame PPU writes, sprite zero hit, timed code, etc...

Sure beats the Atari 2600. That needed lemuring :-)


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: infiniteneslives and 8 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