It is currently Wed Dec 12, 2018 9:34 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Wed May 02, 2018 9:24 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 126
I've learned a bit about what the NES is capable of, and what the limits are that it faces when drawing an image on the screen.
I'm curious today, what about the GBC?

Overall, the Game Boy seems to be largely similar to the NES. They have the same inputs, they have almost the exact same sound capabilities, and superficially they look like they have nearly the same rendering capabilities. Tiles are stored in 8x8x4 sections, although the original Game Boy effectively had only one palette of four colors, making color palettes pointless. But the Game Boy color seems to have a much more varied amount of color options than the NES. So I'm wondering what it's basic restrictions are. What colors can it display? How many palettes? How are the palettes forced to be divided? How many sprites, layers, etc? And does it have restrictions for drawing scanlines (if they would even be called that on an LCD screen)?


Top
 Profile  
 
PostPosted: Wed May 02, 2018 9:57 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20861
Location: NE Indiana, USA (NTSC)
Game Boy Color palettes are RGB, 5 bits per channel, not unlike the Super NES. There are eight four-color background palettes and eight three-color sprite palettes. GBC is the only tiled PPU I know of where all four colors are distinct across the different background palettes. On all others (NES, TG16, Genesis, Super NES, GBA), all tiles share the same color 0, but not on GBC. (On Commodore 64 multicolor mode, all tiles instead share colors 1 and 2.)

It has 12288 bytes of CHR RAM, enough for 768 tiles. That's 256 for sprites, 256 shared between sprites and background, and 256 for background.

It has two 32x32-cell tile maps, each with two byte planes. The second plane is analogous to bits 15-8 of tile maps on the Super NES, choosing the palette, which half of the CHR RAM is used, and setting the tile's flipping and priority. As on the TG16, Genesis, Super NES, and GBA, the palettes are assigned on individual 8x8 pixel tiles, not larger 16x16 pixel areas.

The tile maps are drawn with what the NES or Super NES calls 1-screen mirroring, wrapping the 160x144-pixel window in a 256x256-pixel region. Both X and Y scrolling can be changed in hblank. The second tile map is used either for double buffering or for the window, a second (fully opaque) background layer that can occupy the right side, bottom, or bottom right corner, placed with pixel precision. My Game Boy port of 240p Test Suite uses this pixel precision to make the text canvas smoothly slide in and out on the help screens.

Up to 40 sprites can fit in OAM. They are all 8x8 or all 8x16, as on NES. But 10 can fit across the screen, covering up to 50% of a 160-pixel-wide scanline, compared to 8 on the NES, covering 25% of a 256-pixel-wide scanline.

Each frame on Game Boy consists of 144 lines of picture and 10 lines of vertical blanking. Because of peculiarities of the LCD driver, it's a Bad Idea(tm) to turn off rendering outside vblank. So forget about forced blanking to improve video memory bandwidth, as was routinely done on Super NES. When the CPU is set to single speed (1.05 MHz), each scanline is almost exactly the same length in CPU cycles as the NES's: 114 mcycles for Game Boy compared to 113.667 for NES. Though vblank is much shorter (10 lines compared to 20 on NES or 38 on Genesis or Super NES), video memory bandwidth during vblank is greater on GBC because of DMA, and even without DMA, the Game Boy CPU's slightly better IPC for sequential processing somewhat balances out the shorter vblank. In addition, both the Game Boy and the GBC allow video memory access during hblank.

Further reading: Pan Docs on GbdevWiki


Top
 Profile  
 
PostPosted: Wed May 02, 2018 10:51 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7817
Location: Seattle
Marscaleb wrote:
although the original Game Boy effectively had only one palette of four colors, making color palettes pointless.
Not entirely. Backgrounds and two separate groups of sprites used three separate palettes, meaning that each could be faded independently.

And I guess the two separate sprite palettes lets you do trivial palette swaps, but that's hard to make that interesting with only 2bpp output.

Quote:
What colors can [the GBC] display?
The other important thing is that the gamma of the original GBC screen is extremely high. Color values in the range 0-F cover the vast majority of the range; colors above that apparently bleed over. (relevant section in gg8 pandocs)


Top
 Profile  
 
PostPosted: Wed May 02, 2018 11:43 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 126
So wait, it can actually access the full spectrum of 15-bit color? And eight palettes for sprites and BG each? Holy crap!
I suppose I shouldn't be too surprised, since the GBC came out in the era of the Nintendo 64, and it wouldn't exactly be hard to up the stats at least just a little, but still, I've long been under the assumption that the Game Boy was roughly the same as the NES, minus color, and the Game Boy Color was basically the same hardware but with color added.

...How do these stats compare to the original Game Boy?


Top
 Profile  
 
PostPosted: Thu May 03, 2018 6:30 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20861
Location: NE Indiana, USA (NTSC)
Compared to Game Boy Color, Game Boy has no double-speed mode on its CPU (thus locked at 1.05 MHz instead of 2.1), half the video memory, and no DMA to VRAM. This cuts CHR RAM in half (384 unique tiles instead of 768) and removes the tilemaps' second plane. In addition, the display of the original Game Boy (DMG) and Game Boy Pocket (MGB) is noticeably slower to react to changes in brightness than that of the GBC, causing rapidly moving sprites and backgrounds to appear motion-blurred. This caused some developers to make 20 or 30 fps engines instead of 60 and to heavily abuse flicker for translucency, which bit the developers of Batman and Serpent in the butt once Super Game Boy came out and showed 30 Hz strobes for what they are.

But mono still has the window (and associated second tilemap), DMA to OAM (which is faster than on NES because it's shorter, and a byte is copied every cycle instead of every 2), and VRAM access during hblank. It has one 4-color palette for backgrounds and two 3-color palettes for sprites, with 2 bits per channel. It was common to see one palette defined as (white, light gray, black) and the other as (white, dark gray, black), especially in things like fighting games to tell mirror match contestants apart. In 144p Test Suite, the palette difference also adds detail to Hepsie's outfit.


Attachments:
Hepsie_GHZ.gif
Hepsie_GHZ.gif [ 2.79 KiB | Viewed 3201 times ]
Top
 Profile  
 
PostPosted: Thu May 03, 2018 12:06 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 126
So the Game Boy Color's stats are basically exactly double of the original Game Boy.
That's one of those things where I in no way thought of that, but when I find out about it, seems super obvious and I'm not even surprised.
If it needs to play original game boy games and you want to have game cartridges that work on both systems but give extra enhancement to one, making the processor and RAM exactly double is perhaps the smartest way to handle that. When running on classic hardware, just drop out every other cycle. Brilliant in its simplicity.

And I never thought about it before, but of course the sprites still need palettes. The system displays only four colors but the sprites still need a transparency.

It has half as many tiles, but how are they divided up?
I mean, on the NES there was a bank of 256 for sprites and a bank of 256 for backgrounds. It makes perfect sense that way, too. One byte to refer to what tile is used, and what bank it looks in depends on if its drawing a BG or sprite (and what mode it is using for how they are stored, but still.) Neither 384 nor 768 are easily accessible with a single byte. I can imagine the original game boy works the same as the NES, but with less memory for tiles, so it could still divide the tiles into two banks but asking for any tile above 192 (or 191) would return an error of some sort (or maybe grab a tile from the other bank, that would be neat!) but otherwise it would need some additional data to be processed to access the other tiles. Of course it is possible, but for 1989 tech that is designed to run on four AA's for 30 hours, well, it seems a little surprising.

...oh yeah, and how many sprites can they each handle in a frame?


Top
 Profile  
 
PostPosted: Thu May 03, 2018 12:23 pm 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 266
Location: Seattle
The 384 tiles are shared between sprites, the background, and the window, but each can only refer to a 256-tile subset. From tepples' link:

Quote:
There are three "blocks" of 128 tiles each : block 0 is $8000-87FF, block 1 is $8800-8FFF, block -1 is $9000-$97FF. Tiles are always indexed using a 8-bit integer, but the addressing method may differ. The "8000 method" uses $8000 as its base pointer and uses an unsigned addressing, meaning that tiles 0-127 are in block 0, and tiles 128-255 are in block 1. The "8800 method" uses $9000 as its base pointer and uses a signed addressing. To put it differently, "8000 addressing" takes tiles 0-127 from block 0 and tiles 128-255 from block 1, whereas "8800 addressing" takes tiles 0-127 from block -1 and tiles 128-255 from block 1. (You can notice that block 1 is shared by both addressing methods)

Sprites always use 8000 addressing, but the BG and Window can use either mode, controlled by LCDC bit 4.


Top
 Profile  
 
PostPosted: Thu May 03, 2018 12:37 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 126
...the window?

Is that the border you'd see in the super game boy?


Top
 Profile  
 
PostPosted: Thu May 03, 2018 12:49 pm 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
No, the window is a second (less versatile) background layer, as tepples said above. It's mostly used for drawing status bars.


Top
 Profile  
 
PostPosted: Thu May 03, 2018 1:07 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20861
Location: NE Indiana, USA (NTSC)
Game Boy has three 2K (128 tile) banks of CHR RAM, which I'll number 0, 1, 2. (The part of VRAM that would be bank 3 is instead used for tile maps.)

Sprite tiles $00-$7F are always from bank 0.
Sprite tiles $80-$FF are always from bank 1, as are background tiles $80-$FF.
Background tiles $00-$7F can be from bank 0 or 2 depending on the BG CHR bank bit in LCDC. So you can have either banks 2 and 1 (LCDC bit 4 clear) or banks 0 and 1 (LCDC bit 4 set).

GBC adds three additional banks of CHR RAM, which I'll number 4, 5, and 6. Each sprite and each tilemap entry have an "add 4 banks" setting in bit 3 of the attributes.


Top
 Profile  
 
PostPosted: Thu May 03, 2018 6:20 pm 
Offline
User avatar

Joined: Fri Sep 11, 2015 10:39 am
Posts: 126
Man. Eight color palettes per layer. 256 more tiles. Palettes can use any 15-bit color.
Just for any one of those traits, I want to shift my project to being a GBC game. The lower resolution is more than made up for with those advances.

...But at the same time it feels kind of like "cheating" to switch to something so advanced.


Top
 Profile  
 
PostPosted: Thu May 03, 2018 6:34 pm 
Offline

Joined: Sun Jan 26, 2014 9:31 am
Posts: 292
Marscaleb wrote:
Man. Eight color palettes per layer. 256 more tiles. Palettes can use any 15-bit color.


You can regularly get away with more than 8 BG and 8 OBJ palettes per-frame. It's possible to transfer new palettes during H-Blank, so once you reach a certain screen line, say like Line 20, you can setup all new colors. A handful of games did this (Alone in the Dark, Tomb Raider). This requires some careful planning, however, otherwise you could overwrite some colors at the wrong time.


Top
 Profile  
 
PostPosted: Tue Jun 05, 2018 10:05 am 
Offline

Joined: Tue Jun 05, 2018 10:01 am
Posts: 2
tepples wrote:
Compared to Game Boy Color, Game Boy has no double-speed mode on its CPU (thus locked at 1.05 MHz instead of 2.1), half the video memory, and no DMA to VRAM. This cuts CHR RAM in half (384 unique tiles instead of 768) and removes the tilemaps' second plane. In addition, the display of the original Game Boy (DMG) and Game Boy Pocket (MGB) is noticeably slower to react to changes in brightness than that of the GBC, causing rapidly moving sprites and backgrounds to appear motion-blurred. This caused some developers to make 20 or 30 fps engines instead of 60 and to heavily abuse flicker for translucency, which bit the developers of Batman and Serpent in the butt once Super Game Boy came out and showed 30 Hz strobes for what they are.

But mono still has the window (and associated second tilemap), DMA to OAM (which is faster than on NES because it's shorter, and a byte is copied every cycle instead of every 2), and VRAM access during hblank. It has one 4-color palette for backgrounds and two 3-color palettes for sprites, with 2 bits per channel. It was common to see one palette defined as (white, light gray, black) and the other as (white, dark gray, black), especially in things like fighting games to tell mirror match contestants apart. In 144p Test Suite, the palette difference also adds detail to Hepsie's outfit.


Why are you saying the cpu runs in 1.05mhz, when the clock speed is 4.1943mhz? Are you talking in machine cycles, or is this the real clock speed?


Top
 Profile  
 
PostPosted: Tue Jun 05, 2018 10:37 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20861
Location: NE Indiana, USA (NTSC)
NES:
The master clock is 21.5 MHz, same as Super NES.
The dot clock is 5.4 MHz, same as Super NES.
The CPU takes multiples of twelve master clock cycles to do anything because of the divide-by-12 behavior of the clock regulator. (On Super NES, this is usually 6 or 8 depending on the address bus.)
The effective speed of the CPU is 1.8 MHz, or 1.8 million machine cycles per second.

Game Boy:
The master clock is 4.2 MHz.*
The dot clock is 4.2 MHz.
The CPU takes multiples of four master clock cycles (or "tstates") to do anything because of a state machine in the CPU core.
The effective speed of the CPU is 1.05 MHz, or 1.05 million machine cycles per second.
Game Boy Color can run at double speed, which is 2.1 million machine cycles per second. Enabling double speed mode will flash the screen briefly, so it's something that a game will usually set and then leave on or off.

One difference between the Game Boy's CPU (Sharp LR35902) and more common CPUs that it resembles (Intel 8080 and Zilog Z80) is that while the LR35902's microcode state machine always divides by 4, the one in the 8080 and Z80 divides by 3 to 5 depending on what part of what instruction is being run. This variable length of a machine cycle ("mcycle") in input cycles ("tstates") is probably the origin of the difference between how Z80 programmers count cycles (as tstates) and how LR35902 programmers count cycles (as mcycles).


* The Super Game Boy uses a slightly faster master clock source derived by dividing the Super NES 21.5 MHz master clock by 5.


Top
 Profile  
 
PostPosted: Tue Jun 05, 2018 5:42 pm 
Offline

Joined: Tue Jun 05, 2018 10:01 am
Posts: 2
tepples wrote:
NES:
The master clock is 21.5 MHz, same as Super NES.
The dot clock is 5.4 MHz, same as Super NES.
The CPU takes multiples of twelve master clock cycles to do anything because of the divide-by-12 behavior of the clock regulator. (On Super NES, this is usually 6 or 8 depending on the address bus.)
The effective speed of the CPU is 1.8 MHz, or 1.8 million machine cycles per second.

Game Boy:
The master clock is 4.2 MHz.*
The dot clock is 4.2 MHz.
The CPU takes multiples of four master clock cycles (or "tstates") to do anything because of a state machine in the CPU core.
The effective speed of the CPU is 1.05 MHz, or 1.05 million machine cycles per second.
Game Boy Color can run at double speed, which is 2.1 million machine cycles per second. Enabling double speed mode will flash the screen briefly, so it's something that a game will usually set and then leave on or off.

One difference between the Game Boy's CPU (Sharp LR35902) and more common CPUs that it resembles (Intel 8080 and Zilog Z80) is that while the LR35902's microcode state machine always divides by 4, the one in the 8080 and Z80 divides by 3 to 5 depending on what part of what instruction is being run. This variable length of a machine cycle ("mcycle") in input cycles ("tstates") is probably the origin of the difference between how Z80 programmers count cycles (as tstates) and how LR35902 programmers count cycles (as mcycles).


* The Super Game Boy uses a slightly faster master clock source derived by dividing the Super NES 21.5 MHz master clock by 5.


So the clock speed of the nes is lower than the gameboy clock, because the gameboy has a clock speed of 4.1943mhz and the nes has a lower clock rate in the 1mhz region? Or is the 1mhz clock speed of the nes cpu measured in machine cycles as well? Which cpu is more powerful, and which one is clocked higher? And is saying the gameboy clock speed is 4.4.1943mhz, the same thing as saying the new clock speed is 21.5mhz? What would the master systems cpu clock be in machine cycles?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 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