Gameboy versus NES in terms of power

You can talk about almost anything that you want to on this board.

Moderator: Moderators

UncleSporky
Posts: 385
Joined: Sat Nov 17, 2007 8:44 pm

Gameboy versus NES in terms of power

Post by UncleSporky » Mon Jun 28, 2010 2:06 pm

I was reading on another forum about the relative strength of handhelds versus their contemporaries on the console side, and it made me realize I really don't know much about the difference between the GB and NES.

While tech specs are available all over the place, that doesn't always provide the whole picture. For example, Wikipedia say that the NES has a 1.7~ MHz processor with a 5~ MHz PPU, while the GB is stated as having a 4.1~ MHz processor. I didn't see anything about a PPU, did that single processor have to handle it all? If so, what does this work out to as far as relative power?

With the GB quoted as having 8k RAM and VRAM, coupled with no need for detailed color information and a much smaller screen...if it uses similar methods as the NES does for display, these aspects alone are much better than the NES. And it could handle much larger cart sizes.

Yet most games do not feel equal in terms of power and speed. This could be due to developers unfamiliar with the technology, or B teams being put on GB projects, or perhaps some other hidden hangups that I don't know about. Maybe they just made games slower so that the ghosting wouldn't be so bad! And it's true that four color grayscale with smaller resolution makes it harder to capitalize on.

What do you guys know about this? If you had to compare the two, what are the main strengths and weaknesses, and why?

User avatar
Bregalad
Posts: 7872
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Mon Jun 28, 2010 2:14 pm

And it could handle much larger cart sizes.
Any cart-based system can handle infinite memory theorically.

The GB has only 384 tiles, while the NES can handle 512. The NES has color (obviously) that the GB lacks.
The GB has a built-in scan-line IRQ counter, and other reliable registers to synchronize with the rendering.

The GB can handle a non-scrollable "window" which can act as a second BG layer WITHOUT any IRQ code. Combined with IRQ code, it can lead to awesome stuff as seen in Castlevania II (GB).

The GB can write to VRAM during HBlank while the NES can only do that during VBlank, so there is more theorically possible crazy tile updating possible on the GB.

The GB can handle 10 sprites per line instead of just 8, but has only 40 sprites instead of 64.

Sound-wise, Channel 3 can play different waveforms (instead of just triangle), but Channel 2 has no hardware sweep, and the noise channel sound like crap compared to the NES (IMO anyway - it might just be me). There is no DPCM channel.

Other than that (and the obvious CPU difference) both systems are really similar. The reason games feels so inferior is that they are made slow on purpose because of the crap LCD screen (fortunately the GBC fixed this).
Life is complex: it has both real and imaginary components.

tepples
Posts: 21949
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Gameboy versus NES in terms of power

Post by tepples » Mon Jun 28, 2010 2:19 pm

UncleSporky wrote:Wikipedia say that the NES has a 1.7~ MHz processor with a 5~ MHz PPU, while the GB is stated as having a 4.1~ MHz processor. I didn't see anything about a PPU, did that single processor have to handle it all? If so, what does this work out to as far as relative power?
The PPU in the GB, GBC, and GBA is on the same IC package as the CPU.
With the GB quoted as having 8k RAM and VRAM, coupled with no need for detailed color information and a much smaller screen...if it uses similar methods as the NES does for display, these aspects alone are much better than the NES.
GB CPU: 8 KiB RAM
GB PPU: 6 KiB VRAM for CHR, 2 KiB VRAM for nametables (hardwired to single-screen mirroring), 40 sprites, 10 sprite slivers per scanline

Noticeable improvements from the NES to the Game Boy that affect video:
  • Built-in scanline counter with IRQ.
  • The PPU always uses CHR RAM. This, along with the increased CPU RAM, makes data compression more practical.
  • GB PPU gets off the bus during part of horizontal blank, allowing for more VRAM bandwidth.
  • VRAM is memory-mapped so that no "increase by 1"/"increase by 32" port scheme is needed.
  • A smaller screen (160px wide) with more sprite slivers per scanline (10 slivers = 80 pixels) translates to 50% coverage before dropout happens, compared to 25% on the NES (or 100% on the Genesis or Super NES, or roughly 400% on the GBA). This allowed later games on the Game Boy Color to use overlays (compare to Mega Man's face) more often.
  • The second nametable can be used as a window to display a fixed status bar. This can be an ordinarily horizontal bar on the bottom or (as seen in Quarth, Tetris Attack, DDR GB, and other vertically scrolling games) an MMC5-style vertical bar on the right.
Maybe they just made games slower so that the ghosting wouldn't be so bad!
After all the LCD motion blur of the first Super Mario Land, I think I understand why games such as Super Mario Land 2 and Pokemon run at 30 fps or slower. Did games from the Super Game Boy era and later detect the SGB to enable 60 fps mode?


EDIT: Bregalad got in before me, but...
Last edited by tepples on Mon Jun 28, 2010 2:23 pm, edited 1 time in total.

User avatar
Dwedit
Posts: 4301
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Mon Jun 28, 2010 2:22 pm

On the GB, instructions take multiples of 4 cycles, with timing ranging from 4-24 cycles. On the NES, instructions take 2-6 cycles.

Here's a sample routine I just made up to compare the GBZ80 with the 6502:

Code: Select all

;GB code to XOR a small range of memory with FF
loop:
	ld a,(hl) ;8
	xor $FF  ;8
	ldi (hl),a ;8
	dec c    ;4
	jr nz,loop  ;8

;NES code to XOR a small range of memory with FF
loop:
	lda mem,y  ;4
	eor #$FF   ;2
	sta mem,y   ;4
	iny   ;2
	dex   ;2
	bne loop ;3
So for this small example, the GB code is 36 cycles per iteration, while the NES code is 17 cycles per iteration.

So GB is about half as fast per instruction, and it's clocked about twice as fast as the NES to make up for it.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Mon Jun 28, 2010 3:34 pm

But the GBC in Double Speed mode probably is faster though maybe not by much than the NES CPU. Also I think GBC featured some kind of DMA.

Back when GB was still going strong, I don't think I ever noticed the ghosting issue. Probably because I didn't play many of the fast paced games like Contra (Operation C). But I did awhile ago in modern times, try to play some on my GB Pocket. The ghosting blur was terrible and annoying me alot. It made the hard to see enemy projectiles and harder to see and the blurring itself is distracting.

I don't own a GBC, and never tried GB games on a GBA so I don't know about their screens. But the GBA SP (original model) was/is ideal for playing older fast paced GB games. No ghosting issues to worry about.

User avatar
tokumaru
Posts: 11646
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Gameboy versus NES in terms of power

Post by tokumaru » Mon Jun 28, 2010 3:45 pm

tepples wrote:The PPU always uses CHR RAM.
This is not really an improvement. Not everyone thinks that CHR-RAM is better than CHR-ROM, but even if that was the case, wouldn't you say that the system that gives you the option of using one or the other is better in this regard?
VRAM is memory-mapped so that no "increase by 1"/"increase by 32" port scheme is needed.
I'm not sure this is an improvement either, but that might be because I'm not familiar with the instruction set of the GB's CPU. On the NES, this automatic address increment saves a lot of time. Writes to VRAM could be slower if indexed addressing was necessary and if the index didn't match the one used for reading the data transfers would be much slower, since you'd have to maintain two pointers/indexes.

I know that the Z80 has some block transfer instructions that could work well for this purpose, but I don't know if the GB's CPU kept them.

I'm sure that technically the GB could have games as fluid as on the NES, but as a player I feel that most GB games are very slow. Maybe this is because of the LCD issue you guys mentioned. But even if this is the case, I see that a lot of games have something I hate: sprite and background misalignment. There seems to be some kind of delay that causes sprites to not properly follow changes in name table scrolling, which causes them to blend very badly with the background. I know some NES games suffered from that too, but it was much more common on the GB.

In fact, another machine that appears to suffer from overall slowness if the Master System/Game Gear. A lot of games feel terribly laggy, and maybe in the case of games shared between both platforms it also had to do with LCD blur.

The thing is that the GB combined with the SMS gives me a very bad impression of the Z80, almost like it can't keep up with fast-paced games. I know this is just an impression though, because even though this wasn't so common both platforms had really fluid games (Daffy Duck in Hollywood for example is a game that I find amazingly fluid on the SMS - the YouTube video doesn't even do it justice).

tepples
Posts: 21949
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Gameboy versus NES in terms of power

Post by tepples » Mon Jun 28, 2010 3:53 pm

Dwedit wrote:On the GB, instructions take multiples of 4 cycles, with timing ranging from 4-24 cycles. On the NES, instructions take 2-6 cycles.
The 6502 has a two-phase clock, and I bet that's part of why the Z80 both could be and needed to be clocked twice as fast.
UncleSporky wrote:the GB is stated as having a 4.1~ MHz processor.
MottZilla wrote:Double Speed
I didn't think UncleSporky was talking about GBC-exclusive features; otherwise, I would have mentioned more than just one of them.
tokumaru wrote:This is not really an improvement. Not everyone thinks that CHR-RAM is better than CHR-ROM, but even if that was the case, wouldn't you say that the system that gives you the option of using one or the other is better in this regard?
Not having the option lowers pin count, which lowers complexity and price of the cartridge. This is especially important if customers will have to buy two copies of the game for a two-player match.
I see that a lot of games have something I hate: sprite and background misalignment.
I saw it in Wario Land. It was probably there because even the developers didn't notice it after having tested the game exclusively on the Game Boy's slow-@$$ LCD.

User avatar
Dwedit
Posts: 4301
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Gameboy versus NES in terms of power

Post by Dwedit » Mon Jun 28, 2010 4:03 pm

tokumaru wrote:
VRAM is memory-mapped so that no "increase by 1"/"increase by 32" port scheme is needed.
I'm not sure this is an improvement either, but that might be because I'm not familiar with the instruction set of the GB's CPU. On the NES, this automatic address increment saves a lot of time. Writes to VRAM could be slower if indexed addressing was necessary and if the index didn't match the one used for reading the data transfers would be much slower, since you'd have to maintain two pointers/indexes.

I know that the Z80 has some block transfer instructions that could work well for this purpose, but I don't know if the GB's CPU kept them.
16-bit register pair HL has a load/store and increment instruction, and this is exclusive to the GBZ80. Regular Z80 doesn't have it.
Usually you use HL and DE as your registers for copying memory, and BC as the bytes remaining counter. So one register pair has auto-increment, the rest don't.

The real Z80 has the LDIR instruction which copies bytes from HL to DE BC times. Someone told me that an unrolled loop of LDI instructions was faster.

The fastest way to copy to VRAM (prior to GBC's DMA) is to use a series of LD HL,xxxx \ PUSH HL instructions with the stack pointer pointing to VRAM. Monster Max does that.

I'm sure that technically the GB could have games as fluid as on the NES, but as a player I feel that most GB games are very slow. Maybe this is because of the LCD issue you guys mentioned. But even if this is the case, I see that a lot of games have something I hate: sprite and background misalignment. There seems to be some kind of delay that causes sprites to not properly follow changes in name table scrolling, which causes them to blend very badly with the background. I know some NES games suffered from that too, but it was much more common on the GB.
You can have sprites and scrolling misaligned on ANY system. This was just horrible programming.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
tokumaru
Posts: 11646
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Gameboy versus NES in terms of power

Post by tokumaru » Mon Jun 28, 2010 4:35 pm

Dwedit wrote:You can have sprites and scrolling misaligned on ANY system. This was just horrible programming.
I know. I was just saying that for some reason this happens a lot in GB games, maybe because the effect is hard to notice on the blurry LCD, like tepples pointed out. It's still a pretty stupid mistake though.

UncleSporky
Posts: 385
Joined: Sat Nov 17, 2007 8:44 pm

Post by UncleSporky » Mon Jun 28, 2010 7:41 pm

Thanks for the rundown. I suspected as much - better in tech specs but worse in the physical graphics department. It's a shame they had to build games around the display being poor.

Also tokumaru, that game looks amazing. Can't believe it's 8-bit. I knew the Master System looked much better than the NES but I didn't know it could go that far, that's essentially a Genesis game with simpler music.

tepples
Posts: 21949
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Jun 28, 2010 8:20 pm

SMS games can look better than NES games for a few reasons:
  • Background tile flipping.
  • Each background tile can use either the background palette or the sprite palette.
  • Each background tile can use any of the 448 tiles in CHR RAM, not just 256.
  • Priority is on the background tiles, not the sprites.
  • Here's the big one: Instead of bits 2 and 3 coming from the attribute table, they come from the pattern table because SMS's VDP has 16 KiB of VRAM, 14 KiB of that being CHR RAM. This means each tile can hit all 16 colors of the palette.
  • The palette is 2-bit-per-channel RGB instead of hue-value, allowing desaturated colors.
  • Built-in scanline counter IRQ.
  • Picture height can be set to 192, 224, or 240 lines, allowing extending vblank without any IRQ or cycle-timing hassle.
One disadvantage: SMS games have to do sprite tile flipping in software.

Though Game Gear kicked Game Boy's behind in graphics, Game Boy redeemed itself in sound because of the Game Boy APU's far more varied waveforms. Sure, the SMS and Game Gear allow clocking looped noise from channel 3's frequency, but the Game Boy has a friggin' wavetable on channel 3.

User avatar
tokumaru
Posts: 11646
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Mon Jun 28, 2010 9:07 pm

I think that if the SMS had as much support from developers as the NES had back then we would have seen some very interesting games. But since Nintendo demanded exclusivity the SMS didn't stand a chance. That machine has a lot of potential that was not well explored, as most of its games are trivial from a technical point of view.

tepples
Posts: 21949
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Mon Jun 28, 2010 9:38 pm

tokumaru wrote:I think that if the SMS had as much support from developers as the NES had back then we would have seen some very interesting games. But since Nintendo demanded exclusivity the SMS didn't stand a chance.
Probably because Sega ran a faster console cycle than its competitors. It put out SMS, MD, CD, 32X, Saturn, and Dreamcast, in the same time that the other company put out only three consoles. SMS was Sega's leading console in North America for barely over three years: June 1986 through August 1989 when Sega was promoting the Genesis with "Nintendon't" wisecracks. NES had nearly twice that time to mature: October 1985 through August 1991. Perhaps more of these "very interesting games" might have come out on Game Gear if it had actually had some battery life behind it.

User avatar
Bregalad
Posts: 7872
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Post by Bregalad » Tue Jun 29, 2010 1:52 am

In fact its the reason I don't like Sega much : There is so many of their console it's a headache to me. To worsen this, some of them have multiple names within regions I think increasing the headache further.

And Sega did really NOT care about sound at all (at least not for their first consoloes), having better graphics but crappy sound isn't really interesting to me - for me sound play a major part in a game, as much as graphics, and shouldn't be overlooked.

And I don't think Nintendo claimed exclusivity - Double Dragon, Battletoads, Contra, Gradius, etc... were all released on multiple platforms and the NES. There is many many dual MSX/NES games from japan (although the NES version is the dominant one).

Is the Gameboy CPU a Z80 ? I heard it was a 8080.
Life is complex: it has both real and imaginary components.

mic_
Posts: 922
Joined: Thu Oct 05, 2006 6:29 am

Post by mic_ » Tue Jun 29, 2010 2:32 am

Perhaps more of these "very interesting games" might have come out on Game Gear if it had actually had some battery life behind it.
And maybe if it'd had a double speed mode like the Gameboy Color. I never cared much for the Game Gear, but at least some developers knew how to get the most out of it.
Is the Gameboy CPU a Z80 ? I heard it was a 8080.
The 8080 lacks several instructions that the Z80 has, like some of the bit manipulation / shift instructions, short conditional jumps etc.
The GB CPU has many of those instructions that the 8080 lacks, but they've removed others (e.g. everything dealing with the IX/IY registers or I/O ports), as well as added a few of their own.
And I've never come across an assembler targeted at the GB that used 8080 syntax.
So I'd call it a simplified and customized Z80.

Locked