The NES vs. its contemporary competition

I apologize if this doesn't belong here.

This is one subject that I have not seen discussed in much depth, and I figure that this site should be able to shed some technical light on all 3rd generation consoles, their pros and cons, and which console would've been king had it not been for Nintendo's incredibly aggressive business practices. There's the NES, of course, and it competed with the Sega Master System and Atari 7800 in the home console market. There were also home computers that were also used as gaming devices, the Commodore 64 and the MSX2. I recall reading that the SMS could, I believe, access DMA during V-Blank while the NES could only do so at the end of V-Blank. On the flip side, it was slower. And while it may have been clocked at a higher speed, a 4MHz Z80 is allegedly as powerful and capable as a 2MHz 6502, and despite having superior graphical abilities, it had the exact same sprite display limitations as the NES.

But I want to know more about the other machines, how they worked, what strengths and weaknesses they each had, and how was software development across each platform.

If I remember correctly:

SMS VDP: more colors per tile, bg tile flipping, loading VRAM during draw or vblank, sprite to sprite collision, sprite pixel doubling, built-in scanline counter
NES PPU: vertical scroll split, sprite tile flipping, loading VRAM only during vblank, CHR ROM for rapid tile bank switching, sprite 0 to background collision
Atari 7800 MARIA: weird all-sprite rendering model based on a separate sprite display list for each 160x8 pixel area; GPU shared the data bus with the CPU

SMS audio: fixed 1/2 duty cycle for 3 pulse channels, looped noise with frequency resolution useful for bass, log volume control
NES audio: 1/8, 1/4, or 1/2 duty for 2 pulse channels that can go an octave lower than SMS, triangle channel, noise, linear volume control for pulse and noise, hardware DPCM sample playback
Atari 7800 audio: Same audio hardware as 2600

C64 tape/disk loading time: unbearable compared to the cart consoles

The Japan-only version of the SMS (the "Mark 3") added an YM2413 FM synthesizer, which markedly helped the, er, bloopiness and sometimes lackluster tuning of the SN76489 used in the SMS.

And in Japan, the Famicom has received audio expansion on a per-cartridge basis. I'm not sure how it compares to the VRC7, but I reckon the Yamaha would be 'more advanced' than the sawtooths or custom waveforms of other boards.

Wasn't the sound system of the SMS comparable to that of the Colecovision?

Almost identical.
Same IC. And also the PCjr/Tandy 1000 too

Yes, but the bigger color depth allowed sprites to have more volume, and there was never the need to stack them. The Master System can even pull off good looking fighting games like Masters of Combat without having to resort to the trick of drawing fighters to the background, like happens with Mortal Kombat and Street Fighter.

Another aspect about the SMS that is different from the NES is that each tile in the tile map has a priority bit indicating whether it should be drawn in front of or behind the sprites. This makes it easier to build a complex scene with background and foreground objects. On the NES, drawing priority is defined for each sprite instead, which is more versatile, but harder/slower to control, and some types of sprite masking that are trivial on the SMS, such as walking behind a pillar, require extra sprites on the NES, so they can't be abused.

The SMS was a pretty good machine, and it's a shame we didn't get to see more games exploring its full potential. It would be awesome to have more games like Daffy Duck in Hollywood, Donald Duck: Deep Duck Trouble, Dynamite Headdy, Chuck Rock II, Ninja Gaiden, Land of Illusion, and so on...

If Nintendo didn't pursue 'incredibly aggressive business practices' I don't think that it would matter, because I don't think that was why NES was king. But it seems like you want to just talk about technical superiority?

I'd say the following (though I'm biaised).

Graphics : SMS > NES > C64 > Atari

Sound : NES > C64 > SMS > Atari

CPU : NES > SMS > C64 > Atari

(a 4MHz Z80 is between a 2MHz 6502 and 1MHz 6502 in horsepower)

What I say might be wrong, especially about the Atari because I barely know this machine at all, but it sounds just an upgrade of the 2600 which is, technically, absolutely terrible.
Oh sorry to offend you who like this machine, but honestly, what it runs barely looks like games to me. That's probably because I wasn't born then.

I honestly don't think it's fair to include home computers in this list because they were not design solely for the purpose of running games (despite that the C64 got the SID which is anything but necessary for a business machine)
I just want to go ahead and praise/bash the SMS hardware. Graphically it's fairly advanced, but the sound always ruins the experience for me. There's no bass, no punch to the music at all and that could've been solved with another frequency divider between the Z80 and the SN76489 to make up for the 10-bit period resolution. A lot of games also had very simplistic music, using simple decaying envelopes for everything, which also sounds very weak due to the logarithmic volume. (This could be because bankswitching never was fashionable on Sega consoles) I honestly don't know if there ever was a worse sound chip in game systems in that era (not counting the PAULA in the 2600, that lovely piece of detuned nightmare) , even the AY-3-8910/YM2149F was better despite only having three channels. It could go even lower than the NES triangle and also create bass tones with its incredibly fast envelope generator.

Nobody here is going to mention the SG-1000? (mark I) I mean, that was released the same day, can't be more direct competition than that.


Yeah, but it was an add-on so you may as well not count it =/ Also it wasn't available in the non-Japanese systems at all, so as soon as support for Japan was dropped (which was as soon as the Mega Drive came out) the FM add-on went completely unused. Amusingly, the Mega Drive does allow adding support for the FM add-on, it's even mentioned in the official docs.


If I recall correctly, the SMS FM add-on and the VRC7 are based off the same sound chip.


I think it's outright the same hardware, actually.


A Z80 also tends to need less instructions to achieve the same things as the 6502. It's like the comparison between the 68000 and the 65816, the former wastes cycles like crazy in comparison (even worse than Z80 vs 6502), but it also needs to do a lot less work and is easier to program for.

EDIT: missed this post =P

The original idea for the SID was even crazier, apparently it was going to have 32 channels O_O (they were forced to cut it down to 3 due to time constraints) Also remember the C64 was explicitly made for home use (not business use, which was another computer line for Commodore), so actually good sound support doesn't seem overkill, all things considered =P

I don't know - the C64 was very, very popular for cartridge games and arcade ports. One of these days I need to sell off my old carts. I assume that my Mule64 disk is long bitrotted, hehe.

I own a Franklin Ace (clone of Apple IIe/II+) and wish I had a working drive for it - and that it wasn't in storage in another state. Sigh... Those systems had horrible 1-bit sound (bit-banging on a serial port so single-channel PWM sound) on the 8-bit generation, and wonderful 15-voice synth chip on the 16-bit IIgs version. Graphics were on par with NES and SNES as well and they worked on the same screens so it was a fair comparison - not something like VGA versus EGA versus composite NTSC versus component NTSC(RGB) versus SVHS(S-connector). Processing speed was about the same as well, for obvious reasons. One thing that really makes game system versus home computer comparisons unfair is actually in the console's favor. I'm talking about the patents that prevented home computers from using stuff like hardware sprites, although they did find some alternatives.

If sprites were patented broadly then it's very likely only one system would have had sprites at all. Also it was common for many computers back then to support sprites, it's just that their sprite support was kind of lackluster in comparison (you needed multiplexing to get more than just a handful of objects out of sprites). Also the TMS9918 had some important sprite support (32 sprites on screen!) and it was originally made for computers.

I'm pretty sure there were patents on sprites but those were patents on the specific implementations used in each hardware (down to the smallest details), so that wouldn't have really prevented using the concept of sprites elsewhere. Patent trolling wasn't common back then.

So basically, it seems like there was no truly superior console, as they each had their own quirks that made development easier or harder. Except the Atari 7800, it seems like it had absolutely no chance. From what screenshots I've seen of its games, it seems you could use 8 palettes of three colors (and I assume transparency) just like the NES, except you could use those palettes anywhere and for anything. Palettes weren't exclusive to either sprites or backgrounds, which allowed for greater freedom than the NES.

I included the MSX2 and C64 because they seem to be fan favorites in the retrogaming community, as they have some exclusive titles that haven't been ported to anything else, such as MG2 and Konami's other games for the MSX2, and... whatever the C64 had. Similarly to the Atari 7800, it seemed like the C64's pixels were actually twice as wide as other consoles, and it had only one palette of 16 colors (very bad colors might I add), and those colors could be used anywhere on the screen, not limited to a grid.

Master System had bank switching using one of two mappers.

• Games using Sega's mapper were up to 512 KiB (4 Mbit). MMIO ports at 0FFFDh, 0FFFEh, and 0FFFFh controlled 16 KiB windows at 0000h-3FFFh, 4000h-7FFFh, and 8000h-0BFFFh, though the first KiB (0000h-03FFh) was fixed to bank 0 for predictable boot state. Most games treated windows 0 and 1 as fixed. In a later revision of the mapper chip, window 2 could be switched to RAM for battery save using a fourth control register at 0FFFCh.
• The Codemasters mapper moves the ports to the start address of each window (0000h, 4000h, 8000h) and guarantees that it powers on with bank 0 in window 0. Setting bit 7 of the bank number causes the mapper to put save RAM into the second half of a window. A few Korean games use a subset of the Codemasters mapper that fixes windows 0 and 1 and puts window 2's control register at 0A000h.

Apple II graphics was a dumb frame buffer with only 6 colors, with only 4 usable in one 7x1 pixel sliver, and some colors could be used only in even or odd pixel positions. Apple IIGS graphics was a dumb frame buffer with 16 palettes of 16 colors, with one palette per scanline. Neither had hardware scrolling, something that the IBM EGA and VGA did get.


Apple II had mostly-NTSC-compatible composite out; Apple IIGS had standard-resolution RGB out.


The concept of a video game itself was patented back then, by Ralph Baer of Sanders Associates.


It was common even before then. If you think trolling is new, you'd be surprised at the sort of trolling that went on when the car and the airplane were new.

Now I remember another competitor: Super Cassette Vision (only released in Japan). I have absolutely no idea about how the video hardware works, but the sound is atrocious since it only has one sound channel. Note that it can be tricky, because at first it looks like a pretty weak system, but then there's stuff like this:
https://www.youtube.com/watch?v=V2yb5c1MGcY
https://www.youtube.com/watch?v=J3MLJiE8Gb0

It also has a pretty decent port of Mappy (wtf sionspapa did you have to run straight into the fat cat?):
https://www.youtube.com/watch?v=bMpxiKQcJas

Also wait, it can output raw RGB? o_o


What was the patent?

I'm aware that ROM cartridges almost get patented. At some point the Oddysey was going to start getting cartridges that included a CPU, ROM and RAM in it ("active cartridges") and that was going to be patented. Didn't happen in the end, but could have potentially screwed over following consoles which did include cartridges with active electronic components inside.

I actually forgot about the Super Cassette Vision. That's quite an amusing console, but even if it came a year after the Famicom, the Famicom was space age technology. I guess it faded to obscurity because, tech-wise, it just couldn't hold it's own.

The VRC7 is based on the same chip as the SMS FM, but it has less features. The YM2413 in the SMS has a choice of extra channels or a percussion mode, not present on the VRC7. The built-in patch set is also different.

Oi! Leave the fantastic PAULA chip out of this! Thanks to it, the Amiga blew away the competition for nearly a decade.

The 2600 had the TIA chip for tone generators.

About graphics, the 7800 and C64 (Atari 800, etc.) like many early-80s computers, had 160-pixel wide graphics in high-colour mode, and 320-pixel graphics in monochrome/ 1 bitplane mode. However, over time new screenmodes have been discovered/hacked on the C64 such that you can now have 320x200 full 16-colour screens, usable for cinemas, title screens, etc. (no CPU time for in-game stuff beyond a scroller.)

Actually the C64 was even weirder. You could have either low resolution (doubled pixels) tiles with 4 colors or high resolution (normal pixels) tiles with 2 colors (makes sense, in both cases the bandwidth usage is the same). This could change in a per tile basis, so you could mix both kind of graphics at the same time.

It's really amusing going and flipping back and forth between the VIC-1 (VIC-20) and VIC-2 (C64) and seeing what they changed and didn't change.

Having done some coding for the C64 I felt I would chime in here.

One huge advantage the NES has over something like the C64 is how cheap scrolling is. On the C64 you could only scroll 7 pixels and then you needed to reset the scroll and move all the tiles. The VIC allowed the adress to "Screen RAM" to be moved so you could double-buffer this to help spread the work out over several frames, but "Color RAM" was at a fixed location so it couldn't be double buffered and needed to be completely rewritten on the frame the scrolling is reset.

There are tricks to get around this, something called VSP (Variable Screen Positioning) which tricks the VIC chip into actually scrolling more than 7 pixels, and was used in Mayhem in Monsterland and probably some other games, and also quite a few demos. Unfortunately this trick has the nasty habit of crashing a few C64s.

I would say the most fun thing about the C64 is the fact that the VIC allows itself to be tricked into doing things it wasn't really meant for. Things like multiplexing sprites by moving them after they have been drawn, changing palettes midscreen, changing "videomode" midscreen are all simple to do.

And when it comes to the palette, I think the C64:s 16 color palette is good for what it is. Sure the colors are a little "muted" and not as bright as most other systems, but that helps things out, there are intensity pairs of each color and you could usually use the grays as "inbetween" colors which actually looks better than one would imagine. There are a few examples in these pictures.

Regarding Mayhem in Monsterland, I'm more impressed with the massive title screen taking up most of the screen, and then there being a background behind that. Was this by chance done by taking advantage of the C64's massive 64K RAM, by drawing unique tiles to give the illusion that there's two layers?

As I understand it, the Commodore 64 has eight sprites, each 24px wide, all of which can be on one line. This allows 192px = 60% overdraw. Sprites can be reused multiple times on the screen. If the title screen is what I think it is based on Google Images, 192px wide is about right.

Yeah, looking at that it seems to be sprites (C64 sprites can have 3 colors of which 1 is unique to each sprite and 2 are shared by all, albeit in that case the pixels get doubled in width, which is what happens here).

EDIT: also I need to recheck again but I think that in that video the HUD was edited because it's not showing the entire screen (I think the bottom of the HUD is trimmed out, which is where the text is actually supposed to be)

I also noticed that some graphics appear to be blown up to about twice their size, especially the title screen. Is that part of the C64's hardware, or is that an intentional design choice?

You can expand sprites in X, Y or both directions, so you can actually fill the entire screen and a little more with sprites, very pixly sprites but still!

I found this video that shows off a few games that has some huge sprites

Interesting, what purpose would this serve? Probably to save memory by drawing something small and then expanding it in software, correct? I'm certain that this would still eat up the sprites per scanline limitation, but the C64's is MUCH more lenient than the NES or SMS's.

Speaking of sprite limits, what about the Atari 7800 or MSX2? Allegedly the 7800 could push loads of sprites around with minimal, if any flicker, so either it was 'immune' to flicker, or it just had a high upper limit. The MSX2 might be more along the lines of the NES and SMS, seeing as how Hideo Kojima designed Metal Gear the way it is due to the hardware. I'm certain he went with an overhead play area as that would be less likely to induce flicker.

I found my way over to this wiki, where someone's gone to some effort to explain what's going on.

My best interpretation, having only spent a few minutes to look through it:
The 7800 is approximately a natural evolution of the 2600. Why should you have to spend your CPU's time waiting for each scanline to finish so that you can put new data in it? Internal to the MARIA graphics chip is a pair of linebuffers, and at the beginning of each scanline, it starts calculating the contents of the next scanline. To do that, it uses what Atari called a "Display List", a set of instructions to put what chunks of original memory where into the linebuffer. Unfortunately, the MARIA didn't share the address bus with the CPU (unlike Commodore's VICs), so the more data you wanted it to copy in, the more time it had to steal from the CPU.

This is definitely an oversimplification, but I think it answers the question. The practical limitation for sprites in the 7800 was how much time it took the CPU to set up the display list, and that scaled (superlinearly?) with the number of sprites. So games involving a few very large sprites were comparatively easy.

I did some reading myself on that wiki since you linked it.

To go on an alternate history tangent, from the research I made from this thread and others, it seems like the NES would've won over the other consoles even without Nintendo's draconian policies. The console was just more flexible and easier to work with compared to the competition. The SMS would've seen more success since it could handle graphics a little better, but it would've been curtailed by it's relatively inflexible sound processor. Then again, maybe Sega would've released the Yamaha add-on stateside to compete with the NES' audio, which might've pushed Nintendo into 'fixing' the audio expansion and bring a fresh new batch of games over.

Compared to the C64 and the MSX2, the NES has the advantage of being cheaper, though both machines could possibly outdo the NES in power and capabilities, the latter especially. To do that though, it would require more work to accomplish things the NES has for granted, such as scrolling. The C64 is notorious for having obscene loading times, which would further turn down consumers. So in essence, the NES, as flawed as it is, was the most balanced machine.

Was the NES cheaper even after you figure in the cost of games?

Wasn't the 7800 just a blitter?


The SMS was a lot easier to program (hardware is a lot less buggy and more fault tolerant, plain and simple), the problem is that it came out two years after the Famicom, and by that point Nintendo had already completely taken over the Japanese market and got a serious headstart in the US market as a side effect. (mind you, Sega still managed to get a foothold in the markets Nintendo wasn't paying attention)


Weren't games expensive in general regardless of the platform? Pretty much all software was priced extremely high no matter what it was.

PC games are generally cheaper than console games, which is true then and true now. People could copy their cassettes and distribute them free of charge, and even if you wanted to buy a C64 game, they were rather cheap also. And just like today, the C64 was much more expensive to buy, wasn't it something like $600 at launch? That would get you an NES ($200) as well as eight other games (8*50 = 400), or a Deluxe NES ($250) with seven games, as well as a toy robot and a light gun.

How exactly was the SMS fault tolerant? I'm honestly curious, I reckon a high complexity machine would require as few faults as possible to even operate. And part of the reason why the SMS tanked was because it was handled by Tonka. I'm certain that Sega would've done a "Sega does what Nintendon't" if they did it themselves, but there was really nothing to hold it up. Two years is a long time, and that was enough to get companies on board to make games. Nintendo's exclusivity contract prevented companies from making games for other consoles for two years, and even without it, there's a good chance no one was willing to risk developing for the SMS.

What do you mean? Some graphical aspects were better on the NES (like sprite flipping, sprite priority, the possibility of bankswitching CHR), but the SMS was better in other aspects (higher color depth, background flipping, background priority, built-in scanline counter), so you can't really say it was inferior to the NES. If anything, the higher color depth could make games look much closer to those of 16-bit consoles, something impossible to do on the NES no matter how good artists were.


Does the average player care about that, though? I'm completely clueless when it comes to music/sound, and to me the SMS sounds just fine. To this day I remember several cool melodies of games I used to play, and it never occurred to me that they were technically inferior to the sounds produced by an NES. I think melodies always made a bigger impression on me than how the actual instruments sounded. As long as the melodies were catchy and memorable, I didn't care if they were made with blips and blops or 44KHz 16-bit samples.

About prices.

Here in Sweden you could buy "budget" C64 games on cassette tape for about 50 SEK (about 7 USD in todays exchange rate) during the late eighties/early ninethies, "full price" games cost about 100-250SEK when I looked in a 1990:s computer magazine.

NES/SMS games was usually 2-3 times more expensive than the "full price" C64-games. And you could get 6-8 budget games for the price of one NES/SMS game. However, many times the NES/SMS games were 6-8 better than the budget games aswell

Also, in 86-90 when I think most people bought their 8-bit system here, the price difference between a C64 and a NES or SMS was not that big, perhaps the C64 was a little bit more expensive but definitely not twice the price. My guess would be you could get a NES with 1 or 2 games for the price of a C64. However, if you wanted a diskdrive aswell a C64 was definitely more pricey.

Anyway, I don't think hardware capabilities are all that important in the big scheme of things, it's the games that are. And when it comes to games, I definitely think the NES is the winner of the 8-bit wars. It's game library is huge and there are lots and lots of quality games in there.

I grew up with a C64 and later a SMS and I love both systems. I think the C64 had better sound and the SMS had better graphics than the NES! Still I play way more NES nowadays.

The PPU in the NES is a horrible buggy mess where if you don't write things at the exact moment or don't do things exactly as intended (e.g. OAM getting trashed) it will break down really hard. With the VDP in the SMS the worst that could happen was writes not going into video memory during active scan (and even then you could cram a byte each scanline), and there are settings that couldn't be changed mid-screen but would take effect in the next frame anyway (vscroll). Also not needing to resort to raster effects to make a window HUD helps (the VDP allows disabling scrolling in certain areas of the screen).


I was thinking about this and it's even worse for Sega actually: during the SG-1000 era Sega made every game (any third party games were ports handled by Sega), and if I recall correctly this stayed true during the early SMS days too. In other words, Sega would also be screwed by not allowing third parties into their console in the first place.

Then again I think Nintendo was the first manufacturer to allow third parties to program for their console directly... the Atari 2600 had third party games but Atari never gave permission for that (they even sued for it).

Ah, yes, the "because it's better documented it must be worse" fallacy.
We call that sampling error, by the way.

The only show-stopper in the entire set of our Errata is the DPCM-induced duplicate reads glitch, because everything else fails fast.

This actually continued until the early Genesis; some of the Genesis' pride and joy games (Strider, GnG, and Truxton) were ports handled by Sega themselves. I'm certain there are other third party games that had to be ported by Sega themselves. I'm certain anything with "Reprogrammed game © Sega" was handled in-house.

You might be interested in the book Console Wars, though it's mostly about the later days of the Genesis. I got the impression that Sega of Japan was strongly opposed to criticizing Nintendo directly, Sega of America sorta forced them into it by taking an "ask for forgiveness, instead of permission" approach.

Regarding Yamaha's sound chips, from reading Atari's internal emails I learned that their purchasing contract with Yamaha didn't allow them to use their parts in consumer equipment, just arcade games. I don't know how long that policy lasted, and if it was specific to the YM2151, or their FM stuff in general, but it did make me wonder if Sega and others had run into similar restrictions.

From the same source too, after reading about the Atari AMY sound chip, I found it very disappointing that it was never used at all. It was a digital additive synth with 8 channels, 64 oscillators, and 72 envelope generators. It would have been a very capable sound chip, for sample compression (kinda like MP3 decoding) and synth sounds.

Well, in the case of Sega, Yamaha made their custom ICs so I guess they probably had less restrictions to cope up with as a side-effect.

But yeah, the licensing restrictions were kind of annoying. Supposedly Yamaha had given an exclusive license for their chips on the Adlib sound card and other sound cards couldn't use it in the US. Creative Labs worked around it by covering the Yamaha chips so they couldn't be easily detected (and crushed Adlib in the process). (trying to get a source URL for this one but Google is not helping)

Probably back then, no, but I reckon the NES (and other consoles, such as the C64 and Game Boy) was partially responsible for 'video game music' being an art and not an afterthought. That might also be the case because the NES (and Nintendo) strangled all other options, not unlike how Sony has made Nintendo utterly irrelevant in the home console market since the mid-90s. That said, what if the SMS was more successful, would Mega Man's music be nearly as iconic with the SMS' hardware? What about Contra's intro jingle? The dreaded moon theme from Duck Tales? The SMS, to my knowledge, isn't as gifted when it comes to DPCM playback, so there would be no Sunsoft basslines or those crazy drums in Konami games.

Sonic 2 (Game Gear) Underground Zone is pretty d*mn iconic. Sonic 1 (Game Gear) Bridge Zone was so iconic that Janet Jackson allegedly used it as the basis for "Together Again".

I seem to remember a lot of later SMS games using pitched looped noise for bass lines to circumvent the SN76489 family's 110 Hz minimum square wave frequency.

I think it was an important factor that the NES had graphics capabilities that were competitive for the time, but it was not really important that they be the best. The important thing was that the hardware was versatile and usable enough to make good games, and that the NES had a lot of good games.

Capable developers can make a good game with whatever set of limitations you throw at them. I think Nintendo was able to attract good developers to work on the NES, partly by policy/business arrangment, but also partly by establishing a high enough level of quality in their first-party publishing.


I think the NES was able to stand out strongly from the previous generation, so in this sense the hardware was important. It had to justify buying a new system, especially after how dismal the market had become after the meteoric rise and fall of the 2600. In this respect I think the deliberate support for one-directional scrolling made the largest impact. At the time of launch, hardware good enough to distinguish from the past was a big deal, but contemporary competition soon reduced this to a requirement rather than a standout feature.

The APU of the NES I would say is an accidental success. The design is really clunky, with several features that turned out to be near-useless, and I don't think initial games did much to make it stand out from the competitor's sound hardware. After a few years, though, NES games really put it to great use. I do think that it was quite distinguished at that point against the 3-square PSG or AY.


I got an SMS at the end of 1988, I believe, at which point is was considerably cheaper than the NES, despite being a newer system and probably more costly to make, it was failing enough against the NES that its price went way down.

I have to agree with that. You were not "supposed" to update the registers every frame, but only every note, that is why there is the useless decay units (this is easy and more versatile to do by software) and the useless lenght counters (again, easy to do by software).
The most ridiculous of all is the triangle channel having 2 length counters.

At least the sweep unit is useful because it can update faster than 60Hz.

Also it seems the early games simply does not play music and sound effects at the same time (at least not on the same channel), this idea only came later.

How the APU was better and better used over time is absolutely fascinating. Apparently Mega Man 1 is one of the first games that feature vibrato, and then everyone started to use them, because it sounds much better with them.

I must also say the sound of the SMS is clearly inferior to me. The fact they are stuck at 50% duty cycle and can't go too low in frequency really kills the change to get music you actually enjoy listening.

The Triangle channel on the NES might be the channel with less features, but hironically it's my favourite one. I just love this channel Probably because it's sound is so distinctive on the NES. Square waves and white noise is a common denominator of all PSGs in the world, triangle is also common but the NES' triangle really has it's specific sound.

For my own curiosity, I looked this up: it apparently disabled the XOR behavior of the LFSR, only clocking in the MSB, turning it into a fixed 15- or 16- step sequence (depending on the exact PSG IC used)... so effectively an "extra" ×15 or ×16 for the period.

Yeah, the lack of bass on the SMS PSG is a big problem for it. The periodic noise thing did help a little, but it's got a tinny TIA-esque sound to it, and also can't be used at the same time as regular noise, obviously. As was said, it didn't get used much until later, and still then not very often.

The AY had a similarly weird to use bass available through the envelope unit, though there's some really kooky sounds you can get through various available combinations of tone/noise/envelope. At least the squares could go low enough to make a nice normal bass though, so you didn't have to abuse/use the envelope at all.

The NES triangle is also hard to use since it didn't have a deliberate volume control, but it really does make a good orchestration in combination with the other channels. It has the ability to blend with the others in a natural way when used well, which I can't really say for the PSG's periodic noise bass, or the AY envelope.

I kinda wondered if some of the motivation for including the triangle was so that dull-timbre sounds like the ones in pac-man would be easy to imitate. The 2x wavelength thing does make it seem designed with bass in mind, though.

Well, a lot of arcade hardware at the time had sound made out of discrete components (instead of proper sound chips), and sine waves were pretty common. I suppose that the triangle wave is there to allow doing a (very) crude imitation of those sine waves, although in practice everybody would use the square waves anyway...

Inability to use bass at the same time as noise didn't stop SID composers though.

The NES, Neo Geo, and Atari 7800 were the only consoles to really use CHR ROM. At first, NES games used CHR ROM bank switching to give a separate set of tiles to each game mode. But as ROM sizes soared and mapper ICs gained smaller windows, games started to use it for tile animation. This partly made up for the smaller video memory bandwidth associated with only being able to write about 128-160 bytes to VRAM during vertical blanking. Dr. Mario used CHR animation to jiggle the viruses, an effect later seen in Shiru's homebrew games. Cosmic Epsilon even used CHR banking as a makeshift texture mapper. But before the jiggling grass and quicksand of Super Mario Bros. 2: Mario Madness, did any games make extensive use of CHR animation in the background, be it CHR ROM or CHR RAM?

That's funny you mention that. It seems like the NES was the only console to actually use triangle waves extensively, as other consoles that could do it (C64, Game Boy) only do so on occasion. Many C64 games use the triangle solely for triangle kicks, while not a lot of Game Boy/Color games use the triangle wave. Tetris theme A and Wario Land 3: Above the Clouds (Night) are the only Game Boy/Color songs (that I know of) to prominently use the triangle wave. It also seems like the NES, GB/C, and C64 were the only consoles capable of triangle soundwaves.

Anything with a wavetable could do triangle, so there's also PC-Engine, MSX-SCC, and Virtual Boy, off the top of my head, but probably many others. Of course, once you reach a certain point, arbitrary waveforms are possible on nearly everything.

I know that on the Mega Drive you can get something between a triangle wave and a sawtooth wave with FM (not quite triangle, but eh - think of it like "25% cycle duty triangle wave", whatever that means), I imagine you can do the same with the Master System with the FM add-on (not as accurate since it only has two operators, but at least close).

Also you can get a triangle wave with additive synthesis, if your hardware supports that:
http://upload.wikimedia.org/wikipedia/c ... iangle.gif

I don't understand what this means, at least not in a way analogous to the SMS. You have two other arbitrary channels that can each be playing a bass tone while the third is using noise on the SID. On the SMS, you don't.

Perhaps you're referring to percussion sounds made with short bursts of noise alternating with tonal sounds? Doesn't have anything specific to do with bass, but it's a common technique on SID and AY tunes. It can be done on the NES too, if you really want to, but on the NES it's not a natural solution to a hardware problem like on these other chips.

For what it's worth, I think that despite the SID's great versatility of waveforms, its lack of effective volume control on the channels made the music much more difficult to balance than the NES, which had fairly independent volume on most channels. A great deal of SID music is blaring and loud, and few composers for it had the skill to overcome this limitation.

A lot of FM music is in a similar boat. FM is extremely versatile, but it's very difficult and time consuming to make patches that sound beautiful and balanced together. There are some really wonderful FM game soundtracks, but the average is really rough sounding.

Did anyone mention the Atari Pokey used in the 7800 and other Atari 8-bit computers? I'd say this chip was almost as good as the NES APU. Four channels, 4-bit volume, variable-with pulse, noise, and some other weird waveforms available. The big limitation on this one is the frequency control is only 8-bit, but otherwise it's a really capable chip. I don't think it often got used to the extent it was capable during its commercial run though.


You can get any waveform with additive synthesis (though a triangle is an easier one, since it will require fewer harmonics to approximate well). What game hardware supported that? (Any FM chip can stack sines, but you're really reducing the number of effective channels with way.)

Actually depends on the algorithm (operator layout within a channel), e.g. one of the algorithms in the YM2612 is all four operators being slots (outputs), so that's basically four waves being added (at the cost of no FM). But yeah, I imagine that any 3rd gen system that supported FM would be using 2-op FM with the operators being hardwired serially (so no additive synthesis within a single channel).

Also on the topic of competition:
https://www.youtube.com/watch?v=5WO6_3rDtqM
Parallax O_O

How exactly did C64 games manage parallax scrolling? Is this where the 64K RAM comes into play? They basically draw a bunch of tiles where imagery overlaps? If that's the case, you could do that on the NES, it just wouldn't be very easy due to chewing up a lot of data and the comparatively miniscule RAM. The C64 handles colors a lot differently than the NES, so color attributes can and will clash.



So basically, Nintendo hit the jackpot in terms of hardware design. They really haven't been able to do that again, but the GameCube did come close. It just didn't have GTA, which was the be-all end-all of 6th generation games, but despite being the worst selling Nintendo home console, it had more than twice the games of the N64. They obviously did something right. Now Nintendo deliberately uses outdated hardware, and it has bit them with the Wii U.

Well, that's a gross oversimplification. In Flimbo's Quest (which has parallax scrolling unlike anything I've ever seen in any NES game) I think it's done by storing several versions of the same tiles, offset by different amounts, in addition to updating the parallax when the screen is soft scrolled on an 8 pixel boundary. NES games don't usually work like that, because software scrolling is not required, and VRAM bandwidth is limited.

See City Connection (but rougher), or Metalstorm, Sword Master, and Batman: Revenge of the Joker (smaller, but smoother) for examples of parallax either through redrawing or CHR animating.

I'm aware of all of those games, I'd still argue it's not quite the same. City Connection just looks pretty crappy and choppy in general, Metal Storm/Sword Master/ROTJ have very obviously repeating patterns. Although the parallax in all those games looks good, it's still very NES-like (= CHR switching + mid-screen scroll changes), and it doesn't give quite the same feeling as a true second layer.

In both Flimbo's Quest and Thunderbolt, one of the 'background layers' is much simpler in design than the others, so maybe those would have to be redrawn 8 times to be done on the NES, at least so I think. In Flimbo's Quest, that would be the foreground/playable area. In Thunderbolt, it would be the background.

And I'm honestly kinda impressed with City Connection; would it have killed them to put one sprite at the edges of the 'road' to look smother? I mean the game flickers a lot, but only when there's like three 24-pixel wide police cars on the same line, which it does a lot.

One channel still has to be interrupted to make the noise.


Yes.


Other than that interruption of melody is likely to be more noticeable than interruption of bass.


Triangle kicks interrupt triangle bass all the time on NES.


That and Atari cheaped out on the 7800. It originally intended to put a POKEY in each console but changed to putting a POKEY in each cartridge that needs it.


For a pure triangle, you might get away with 1, 3, 5, and 7, as the 9th harmonic is 38 dB below fundamental. For an NES-like triangle, though, you'll need some way to construct the 31st and 33rd harmonics that carry the aliasing.

Now about parallax scrolling playfields: MSX can't scroll at all, so Pippols for MSX has to store the playfield graphics 8 times in the MSX's CHR RAM.

Has anyone of you seen this? I couldn't find a video of it but the D64 can easily be run in VICE. It's a lot of NES tunes played on the SID, and most of them sounds amazingly like the real thing.

I also found this very cool SID like Famicom version of the music from Cybernoid on the C64, also very impressive stuff but it cheats quite a bit by using VRC6.

The C64 was a pinnacle of American Engineering. It could emulate almost any kind of sound you threw at it, when the NES needs expansion audio. On the flipside, as Rainwarrior said, it has an obscenely loud and harsh sound, and everything just sounds crude. Doesn't the C64 also suffer from some form of power parasitism? One of the components starves the SID of power (or vice versa), which might explain that sound.

Also, I read conflicting information about the Game Boy's audio. Some sources say that it had selectable sound channels not unlike the SID (at least, channel 3 could be either triangle or sawtooth while channel 4 could be either noise or DPCM), while many others say it actually used wavetable synthesis for channel 3. And could the original Game Boy play DPCM samples like the NES? I know there are some GBC games that make heavy use of DPCM, but only a handful of Game Boy games used the sample channel period. I think Pokemon Yellow is the most prominent example.

The current direction of this discussion reminded me of: viewtopic.php?t=7496

Also (further in that thread): http://blog.kevtris.org/blogfiles/nes%20tia/

The GB wave channel is used by almost all games. 32 samples, 4 bits per sample. Some games just make it a square wave, but any tiny wave would fit in there.
Game boy games generally don't play long voice samples, since it takes so much CPU usage to keep feeding out 32 samples over and over again.

Channel 3 on the gameboy, is a single wavetable. Partially controllable volume (full, half, 1/4). Thirty-two four-bit samples in length. So it can be a triangle, just like the NES, or almost anything else chippy.

See the pandocs.

Channel 4 is almost identical to the noise channel on the NES, although they chose a different short polynomial so when selected it's more nearly tonal. Maybe. It uses a 2^22 Hz master clock, so I don't know that the 1.02MHz÷63÷{0.5,1 though 7} tones come out any more enharmonic with Just Temperament than the NES's somewhat-arbitrary 1.79MHz÷93÷random numbers.

No compressed formats in hardware. It's possible to dynamically change the contents of the wavetable as it runs, though.

The GBC was much more amicable than the DMG to processing voice samples in Sound 3 (its wavetable) thanks to its double-speed mode (takes 1/2 the time to generate and update wavetable entries). Perfect Dark and Army Men II make great examples of it. Just about every sound effect in PD seems to use it (gunshots, footsteps, voiced dialog), but Rare always seemed to push the limits of whatever system it used. Except for voice samples that did not need tight timing (or when nothing else is going on) I do not recall Sound 3 being frequently used on the DMG for detailed, synthesized sounds. As mentioned above, Pokemon Yellow is the only one I can think of off the top of my head. If any one else has DMG examples, I would love to hear more about them

Interesting, thanks for the info.

I've always wondered what kind of sound channels the 2600 used. They don't quite sound like square waves, but what else could they be?

@Shonumi: I know the Game Boy port of Joe and Mac has a dinosaur voice sample play before you fight the boss.

No, what I was referring to is that there is no per-channel volume control. Each channel has an ADSR, but this envelope always goes to full volume. There is a global volume control that will fade all three channels at once, and there is a filter which can be applied to any of the channels but it only has global settings, not per-channel (it also had poor consistency across machines, many composers avoided it because of this). As such, there is no easy way to make one channel quiet while another is loud. This is part of the reason why the triangle is more sparingly used on SID, it doesn't compete with the pulse or saw very well. Another trick is to release a note before the attack has finished, which can make a non-sustaining note that doesn't go to full volume. It's a limited technique, but it's enough to have a little bit of volume control. Of course, the ADSR is also fickle and sometime fails.

So, ultimately every way of trying to get per-channel volume on the SID is a bit of a pain. Use the dull timbre of triangle for "quiet" parts. Use the filter to make something quiet, and pray it works on most machines. Abuse the ADSR, usable only without sustain, and sometimes it will fail anyway and produce erratic loud notes. etc.


The parasitic power thing was merely a constant bias on the amplifier that (unintentionally) would let you use the global volume control as a 4-bit DAC under full CPU control. When they revised the SID, though, they used an amplifier with a much smaller bias, so it made things using this trick extremely quiet. So, this was fairly well known, and doesn't really have to do with making music on the chip. Mostly it was used for stuff like speech samples.

Hey, thanks for the heads up. Looked at a YouTube playthrough and I immediately saw what you were talking about. Impressive that you could still move around while the sample plays. There is no hit detection while it plays though? That'd save a lot of cycles necessary for it. Glad you brought that to my attention; it looks technically interesting at any rate.

Weird binary with non-uniform on/off times.

nocash's documentation.

It probably has to cut cycles from other areas while the sample plays, though I think hit detection might be on (player was able to collect something while the sample played). At the final boss, the heart does not start beating until the sample ends, and notice how the player does that surprised look, also right after the sample plays. If it was beating while the player got there, it probably would stop beating to play the sample, and then resume.

It's basically an LFSR with a short period before it repeats, similar to the NES 'periodic noise'. POKEY chip uses that method too, I like it's sound. It was mentioned the POKEY has 8-bit frequency control, but it also has a combined mode where you only have 2 channels with 16-bit frequency. Atari must have liked it pretty well too, at one point they were making quad-core versions of it. I bought a cheap, broke-down Millipede arcade game, at first I was like WTF when I saw that it uses 2 POKEYs. It seems like every enemy type has a sound channel dedicated to it, and it's actually useful when the game starts getting intense.

Another sound chip that uses type of synthesis was in the Atari Lynx. It's LFSR, but for each channel it lets you select the taps and seed value, and I think that is a really cool idea. But I've played some Lynx games (not a lot of them), and I've only ever heard the music use square waves and noise.

If I remember well, there was an easy trick that could be done to simulate per-channel volume, by tricking the ADSR enveloppe. I don't remember, but it was like, setting attack and decay to 0, and the sustain level to your volume. After that, whenever you wanted to change the volume, you had to send a key off and immediately a key on again.
At least I know I managed to pull that trick to completion back when I did some C64 experiments.

I have programmed an audio engine for a GBA game. Apart from a pair of PCM channels, it's the same as that of the original Game Boy. And channel 3 (called triangle in my audio engine after the corresponding NES channel) is in fact 32-step 4-bit wavetable with a 3-position volume control implemented as bit shifting. Once I made a wavetable editor for the GBA in C; I wonder if I still have it.


They're predictably C, D, F, G#, good for covering the underground theme in SMB2 or "Wish" by Nine Inch Nails. And I thought it was a 127-step sequence, not a 63-step sequence.

You forget to mention thast the PCM channels can be coupled easily with DMA1 and DMA2 in order to be refilled automatically, creating an easy way to stream arbitrary audio without monopolizing the CPU.

The GBA wavetable could be banked as well, resulting in 64 4-bit samples if the programmer desired.

(Since we're all over the place, topic-wise...)

Yeah, most games on the Lynx have simply terrible sound, but I recommend tracking down anything by Paul Tonge (Dracula, Jimmy Connors' Tennis, Malibu Volleyball, Battlezone...) as it's excellent, very Turbografx-like. Also Robotron is pretty good. The rest of the games... nah.

this one is even more impressive

That's amazing, the background and foreground elements are about equally complex.

Thought I'd chime in since I regularly work with this platform:

The cool thing is that the LFSR feeds into another unit which can either output the LFSR state directly (a pulse with an amplitude specified by the volume register) or integrate it (either add/lfsr[0]=1 or subtract/lfsr[0]=0 the value in the volume register from the current output amplitude). The latter allows you to get nice triangles as well as some incredibly bizarre waveforms.
You can also disable the waveform generator for any of the four channels and just write to its DAC directly.
One issue is that the LFSR is only 12-Bits. So your percussion will sound a little metallic (especially hi-hats). All things considered though, the hardware gets you great sound for its low complexity.

Most (if not all) of the Lynx games released during the console's life used Atari/Epyx's sound driver and tools, which had the odd restriction of not allowing the use of integrate mode for instruments (only in sound effects). I used these for my first game, and they're not bad tools by any means. But they weren't made with complicated instruments in mind (i.e. vibrato, arpeggios, etc).

I wrote a new driver and toolset for my upcoming game, and did a few covers as practice/tests (warning, I am not a music/audio guy). They might give a better idea of what the Lynx can do.

One thing that has worked for me for hi-hats on NES is alternating between 93- and 32767-step sequences on successive frames. I wonder if alternating 63- and 4095-step LFSRs might work for you.

I did not even think to try that. Thanks!

The background looks pretty weird near rounded edges in the foreground though... Flimbo's Quest simply avoids rounded objects (anything non-rectangle, actually) where the foreground overlaps the background (you can only see such shapes in front of the sky).

Looks cool, although it hard tell in some parts because of the bad quality video. It's probably using the same technique as Flimbo's Quest.

Since we're on the Atari and C64 note, I wonder if any of you who are familiar with NES development have dabbled into development for those machines. They share the same 6502 based CPU, so maybe the main code would be similar across platforms. How each console handles graphics, controls, and other data differs from one to one. Or is adapting to the uniqueness of each platform the biggest challenge, despite using the same (well, similar) CPU?

Atari 2600 is like the opposite of the NES. You run your game logic during Vblank, and spend all your other CPU time drawing to the screen during rendering. Whereas on the NES, you draw during vblank, and spend all the other CPU time running the game logic while the screen is rendering.

Maybe the C64 and the NES have more in common, but things are very different with the 2600. With the 2600, you have about 5320 CPU cycles per frame for game logic (this can vary as you make the picture shorter or taller), versus ~27280 on the NES. This severely limits the amount of calculations you can perform per frame, so you won't be seeing on the 2600 the kind of complex code used for physics, collision detection, etc. you'd commonly find on the NES.

The small amount of RAM (128 bytes vs. 2KB - plus an extra 8KB that wasn't so uncommon) also limits how complex the world model can be. You can't track many objects with several unique attributes, so you end up with simpler/fewer/cloned enemies.

The consequence is that you end up making more extensive use of the Atari 2600 hardware. It has pixel perfect collision detection, so very few games would do it in software. It can automatically clone sprites once or twice, so you can control (and keep track of) a single object that looks like 3 individual objects on the screen (even though they all move together).

In the end, the abstraction from the hardware is not as big as in platforms with more RAM and CPU time.

Nor were most of the Lynx game developers, which was part of the problem...

Don't forget that ROM was limited to 4KB (later there were mappers but for a long time they were stuck with 4KB). Can you even afford to have look-up tables when the ROM is so tiny?

Interesting. What about the 7800, Lynx, or PC-Engine? Those all use some variant of the 6502 (some even say the PC-Engine was essentially an NES on steroids), and IIRC the Lynx got one homebrew game a few years back. I am aware that no two consoles have the exact video or audio controllers, and data regarding the control input would need to be changed accordingly, but could one build an engine for, say, an NES game and then port it (with the needed alterations) to another 6502 based machine? The 7800 would be a challenge since it works much like the 2600 did, and completely backwards from the NES, and the C64 would need a different code to get scrolling to work. As you can tell, I don't know much about how different these machines are.

Sure, as long as the machine the game is being ported to is similar enough to (or a superset of) the original machine. The key is to isolate everything that deals directly with the hardware. For example, you shouldn't have the object AI routines write directly to the OAM for rendering sprites, instead you should have the objects call a "DrawSprite" routine, which deals with the sprite data and formatting it for the sprite hardware. This way, all you have to do when porting the game is rewrite this specific routine, instead of messing with the inner workings of the game.

When you think about it, very little of a game program is about dealing with the hardware (except in extreme cases like the 2600), so as long as those parts are isolated, porting the game to similar platforms is relatively straightforward.

By way of analogy ... the original Macintosh, the Genesis, the Neo Geo, the Amiga, the Atari ST, NeXT machines, really early Sun workstations (everything before the Sun 4), earlier Palm PDAs, and many other things, all used the 68000 or its descendants. Yet I don't think anyone would assert that it would be significantly easier to port a program from one to another solely because they use the same CPU.

I do think it is significantly easier to port amongst the same CPU. Much better than if they had a different CPU. Doesn't mean it's easy. Just easier. There are tons and tons of games that got ported between Amiga and Atari ST, for example. Even more recently, portability between XBox360 and PS3 was made a ton easier because they both had PowerPC architecture.

Now, if you want to find examples where code was shared, go looking. Maybe check out Paperboy on the NES and C64 and see if you can find the same routines in each? Might be tricky to compare, since relocation of code is going to change most of the addresses, but maybe an instruction comparison on trace logs might help find similar regions of code, if they exist. Probably it'd be a lot of work to answer this question properly; would anyone care enough to find out?

There was an Atari ST cartridge called Spectre that used ROM chips desoldered from a Macintosh Plus to run Mac OS.

But the I/O of the Genesis was so different from that of, say, the Mac that games were rarely ported between the two.

But didn't the PS3's awkward architecture, especially the infamous Cell processor, make multiplats suffer? They might share the same architecture, but the PS3 suffered a lot when it came to ports, probably because, at the time, the PS3 was a massive failure and Sony was bleeding money (they still are, but they haven't gone anywhere). They might've been wary about wasting the effort to make a good port for a potentially dead console. On that same token, the Wii U also shares a similar architecture to the PS3 and 360, and it too had several bad ports. On the flip side, it sees very few multiplatform titles, almost as if the Wii U came from a different universe that we cannot comprehend.

According to the NESDev wiki, the NES version of Puzznic uses an illegal opcode, and some believe they copied the core engine from, potentially, the PC Engine version. But as Rainwarrior said, who would care enough to check? That said, has anyone on here dabbled with, say, the PC Engine or Lynx? I know some guy is porting several NES games (specifically Mega Man) to the PC Engine, and I reckon that is largely due to both consoles being very similar and making the porting process comparatively simple.

@Tepples: Congrats on post 12345.

I said easier, I didn't say it automatically makes your port into a perfect copy. There's still lots of work to be done. There were definitely some poorly handled port jobs to the PS3, and a lot of devs were more comfortable leading with the 360 and treating the PS3 as secondary, especially early in the PS3's life. As time went on, though, I think the situation got a lot better. Even in the early days I can't think of very many games that were on both 360 and PS3 that I thought were significantly worse on one platform. Most of the time if it was worse on one, it was in a very minor way. Not even close to the kind of difference you'd see in, say, a Genesis vs SNES comparison.

Also many arcades used the 68000, but in many cases it was done in such a wasteful way it isn't really portable at all. E.g. it wasn't uncommon for Sega's arcade machines to have two or three 68000s, but only one of them really ran the entire game, the other ones barely handled a single aspect of the hardware that was pretty lightweight at that. I guess it could have been for copy protection, but honestly I suspect it was just sloppy programming (in arcades you could get away with just throwing money at the problem).


It's unlikely to happen, since back then ports were nearly always handled by telling third parties to port the game without any assistance whatsoever (not even the original binary, much less source code). Your only hope is when you know it was the same developer the one who ported it.

Not very much on the Lynx, but it is basically a tiny Amiga (or Atari 800) that happens to use a 6502: Framebuffer + killer sprite blitter + math coprocessor.

The PCE is an NES on steroids, as it was made as a direct response to all the limitations of the Famicom/NES, yet still be easy for ex-NES programmers to code for. It is not hard at all to step up from 6502 programming on the NES to 65(c)02 programming in assembly on the PCE.

In the case of the NES, it's not totally true. I found out at least half of my game's code is dealing directly or indirectly with the hardware.

For example the player AI code is not dealing "directly" with hardware but you're still going to poll buttons press from the NES controller, so if you port it to another system a full rewrite will still be needed. The same for code that deals with printing or displaying anything on screen, etc... You won't be directly by writing to $200x, but the way you prepare your buffer and screen alignment is still closely related with hardware.

The button example is not a good one though, because that one can be abstracted easily (although it's true many games that don't support remapping just use the joypad input directly).

Easy to abstract, as Sik pointed out. The code in one of my games to handle a button might look like this:

Would this be portable by changing the routine that fills cur_keys and the value of KEY_B for the new system? But if you were using asl or lsr to check bits in order by putting them in carry, you might have to stop doing that.


That and how the screen width affects level design. A lot of NES level design relies on the screen being 16 metatiles wide by about 14 visible metatiles wide. Super Mario games for Game Boy needed to resort to other measures, such as shrinking the graphics to allow use of a 20x16 metatile grid (Super Mario Land) or centering the camera in front of the player (Super Mario Land 2; Super Mario Bros. Deluxe). These are the same considerations needed when porting Master System games to Game Gear. Some jumps over long pits in Hello Kitty World for Famicom actually become blind jumps in Balloon Kid for Game Boy. Or consider The Great Giana Sisters. Because the C64 pixel aspect ratio is much narrower than that of the NES, each block has to be 24x16 instead of 16x16. And the C64's larger border means fewer metatiles across the screen (320px / 24px per tile = 13.3 metatiles), which is somewhere between the NES and Game Boy.

The breadth of those problems could fill a sizable book.

Regarding resource sharing:
One thing that really impacts resource sharing is how the platform's memory is actually set up. For example, most consoles have execute-in-place media (i.e. code and data are executed and accessed directly from the cartridge), but home computers and actually the Lynx as well were setup to use disks.

On the PC-Engine I use a small mapper to bring the work RAM up to 136KB and accessible ROM up to 8MB. That allows for expansive and modifiable stages, large sound data, etc.

On the Lynx there is 64KB of RAM available, and 16KB of it is lost immediately to two framebuffers. More is lost if you are doing buffer feedback effects or rendering to textures. Your engine / drivers / textures all have to live in the remaining space and still have room left for stage data. While I can access the cartridge, it is extremely slow and byte by byte (it even requires seek times). But that is the only way new data can get in.

In Zaku, all resources for a stage were loaded upfront. The only new data loading during play were music tracks (and that was only once on a track change). This made the stages extremely small and also linear. In what I am working on now, data are loaded during play. This includes new stage data, PCM streaming, and music data. This means that object data (enemies, etc) are being swapped in and out dynamically, which is a huge headache for stage design especially when you want the game to feel fluid.

Large, dynamic stages on the Lynx are extremely difficult. Moving to the PC-Engine (or even the NES), they're significantly easier. But there are other limitations on these platforms. A variable width font renderer can be written in minutes on the Lynx because it uses framebuffers, but it is much more work on the NES or PCE because they use tiles (and have finite bandwidth for moving these tiles in and out of VRAM).
Point is, the 6502 was in so many platforms with so many different ideas regarding what games' requirements are. Yes, you can share some code. But especially nowadays when the only development on these dinosaurs is for the sake of explicitly targeting their unique features or for fun, there is not much point in trying to compromise on performance or game design just to reduce keyboard activity.

If I may interject for a moment, wasn't Hello Kitty World an NES port of Balloon Kid that came out one year or so later?

And seeing how the PCE was an NES without the biggest limitations, I'm a bit saddened that it didn't do so well in the market.

Exactly how slow is the Lynx's cart interface? Are we talking 1x CD-ROM slow, FDS slow, or C64 tape slow? Even the Game Boy Advance has seek time greater than sequential read time, yet it's still fast enough for XIP because the memory controller prefetches up to eight Thumb opcodes from ROM during idle bus cycles (mostly multiply instructions and the pipeline bubbles of load instructions).


Release dates are beside the point I was trying to make that practical level design on one platform turns into leaps of faith on another. Or are you trying to claim that this particular leap of faith was intentional?

You get two registers for reading / writing to the cartridge. However, all they do is either latch or drive the state of the data bus while lowering one of two strobes. The address is determined by the concatenation a 74164 shift register and 744040 counter which are both controlled through some GPIO. The counter is used for the lower address bits (offset), while the shift register is used for the upper bits (block). That's where the seek time comes into play- if your data are aligned on a block boundary, you don't have to perform several reads just to increment the counter until it reaches your correct offset. But the shift register must still be loaded.

More detailed writeup available here courtesy of LX.NET.

Performing a 2MB checksum takes about two minutes, giving ~16KB/s ish. So yes, really slow and really inconvenient.
The Lynx was originally designed to use tapes as its game media, and this was the band-aid to allow it to use traditional cartridges.

Putting a microcontroller in the cartridge to allow address selection by just writing three bytes (after the boot phase anyway, which requires the above setup) would alleviate many of these issues. But that would not have happened back in the day.

What? Your AI should be making decisions based on a few bytes that describe the state of the controllers (currently pressed keys and newly pressed keys, usually), so all you have to change is how those bytes are formed, which is often in an isolated routine. Reading the controllers directly in the game logic is a bad practice I'd expect from those old GBAGuy tutorials (I remember an old tutorial that would strobe the controllers and read the status several times until the button of interest was reached, right in the middle of the game logic, for each button... was that GBAGuy's?), so I really hope you're not doing that.


I don't know about you, but my scrolling engine just spits arrays of tile indices and attributes. As long as the target machine is tile based, converting that data to another format would be fairly straightforward. But even if the hardware was very different, it must have a way of rendering rows and columns of blocks if you expect to port an NES scrolling game to it, so as long as you have isolated "DrawRow" and "DrawColumn" routines which are fed the coordinates of the row or column in the level map, you can modify only those routines to generate data in whatever format you need, even if you're not using name tables that are 32x30 tiles large.

The same goes for sprites... it shouldn't matter if sprites are not made of 8x8 tiles, as long as the same (or similar) visual effect can be achieved in another machine, it's just a matter of changing your "DrawSprite" routine to output data in the appropriate format. You might have to change the meta sprite data as well, depending on how different the new system is.

The point is that as long as the machines aren't severely restricted in resources (like the 2600 is), you can abstract most of the parts that deal directly with the hardware. The NES isn't exactly abundant with RAM and CPU time, but my game designs have always abstracted these details and that never caused a significant impact on performance.

So... MMC1 from heck. An e-book reader would probably use something like CHM compression instead of Huffword. CHM uses LZ-family codec with a few pages in each independently compressed section, which needs several kilobytes of RAM but works fine with slow sequential ROM access. Huffword, on the other hand, needs little RAM but fast random access to the large static dictionary in ROM.


I think the point is that not a lot of other machines with the same instruction set were based on the paradigm of hardware sprites atop a scrollable grid of character cells with modifiable glyphs. Neo Geo was based on vertical strips of 16x16 tiles. And many of the western computers had dumb frame buffer displays, many of which couldn't even scroll the screen in hardware. For example, in HGR mode on Apple II, scrolling the screen took four frames to copy about 8K of data, and horizontal scrolling in increments other than 14 pixels was even slower. Drawing sprites on one of those was a matter of software-compositing the sprites on top of the background tiles and then copying the whole thing to the screen, and Apple II's attribute clash was almost as bad as the Spectrum's (7x1 pixel units instead of 8x8), causing most games to use orange/blue throughout or green/magenta throughout, or just use black-and-white backgrounds. So you'd have to completely rethink a big scrolling game to make it fit the platform.

That's why I said that the more different the systems are, the more extensive the changes to the source code will be.


Then you'd just implement a frame buffer in this specific format in RAM and have DrawRow and DrawColumn modify that. Sprite definitions would also have to be changed to comply with that format.


Sure, this kind of porting wouldn't be the easiest. If you need to keep a frame buffer in RAM anyway, you'd obviously have all drawing routines modify that. However, considering all the differences in the graphics hardware and how long it takes for a full frame update, the whole gameplay would probably have to be reconsidered in this case.

This is one of my favourite things:
https://www.youtube.com/watch?v=C3b4h-MUjGo
(Shadow of the Beast compared across many platforms.)

Interesting video. I never played this game, so I can't say if it's as boring as it appears to be, but if it is, why would they want to port it to so many platforms?!

And more importantly, why are the Genesis (US) and Mega Drive (JP) versions so different from each other?! Looks like 2 independent ports, not that one is an adaptation of the other.

Money, dear boy.


Airwolf had independent ports on Famicom and NES, as did Tetris.

My point was: if the game is indeed as boring as it looks, why would developers think a large enough number of consumers would pay money for it?


You can add Maniac Mansion to that list. I know this happens some times, I'm just wondering WHY. The only reason I can think of that would explain this phenomenon is developers of one region thinking that the port developed previously in another region isn't well done enough. With Maniac Mansion at least, the general consensus appears to be that the Japanese version is crap, with simplistic graphics and tiny rooms with no scrolling. I find this version kinda cute, and its art style somewhat more consistent than in the other version, but I think both are fine.

The US version was the original, and the publisher for Japan wasn't happy with its quality so they demanded it to be remade.

It's a very boring game, in my opinion.

In the original Amiga version, it was quite a visual spectacle. I think this is the primary reason for its popularity. It became a huge hit there, and was subsequently ported to whatever they could manage.

Shadow of the Beast II and III are actually not bad games, I think, but neither of them makes such a big deal about the graphics as the original. They are much more about puzzles.

Shadow of the Beast was one of the first games that really showed of the capabilities of the Amiga hardware with lots of colors on the screen (thanks to the copper) and huge sprites (thanks to the blitter) and lots of parallax scrolling. The music was great aswell.

The game was hugely popular in the late eighties/early nineties because of that.

Unfortunately it's a really boring game to play and I could never understand why it got so many ports.

Here's some interesting information about the Amiga version of Shadow of the Beast for anyone interested.

The PC-Engine did VERY well in the market. It's the TurboGrafx 16 that didn't do so well in its market place. Partially due to Nintendo's business practices.

Actually, I was bringing up something entirely differently. Who's to say the NES game wasn't the original while the Game Boy game was a quick port? Maybe they thought no one would buy it if it was just "Balloon Fight 2", so they released the Game Boy version as a test first in the US, and they finally managed to secure the rights to Hello Kitty to help boost sales?

Also, on the topic of ports, here's an interesting game that has been made for 6502 platforms; Ghostbusters. The original game came out for the C64 (and Atari 800), and it was ported to other consoles, the NES and Atari 2600 specifically. It was also ported to the Apple II, which also used the 6502. I believe most all of the aforementioned ports were handled by Activision themselves, except for the NES port.

Not like the original game was a classic by any stretch, but come on, what the hell happened with the NES port? Was the game just described to them? And how is this game so buggy? King's Knight isn't this buggy, neither is Castlequest, both of which are by the same developer, BITS Laboratory. I reckon that the people who programmed NES Ghostbusters went on to make the original Pokemon games, which are known for being hilariously bugged out.

Nintendo's business practices didn't seem to hinder the Genesis though. From what I gather the problem was that NEC really wasn't much into gaming in the first place so they didn't care that much about their console. Then later the PC-FX flopped (due to lack of 3D hardware) and they quit without considering it much.


To be fair, to get the most serious glitches in Pokémon you need to be actively looking for them...

If what I read is correct, the Genesis was only successful because it allowed Sega to challenge Nintendo's status in the market. If Nintendo didn't have those scary spooky policies, chances are the Genesis wouldn't have done so well; they wouldn't be able to prop themselves up by attacking Nintendo. As it turns out, Nintendo's policies only turned around to bite them, and no matter what they do, they won't get their NES era status back. That said, Nintendo is good enough with no third party support, though many consumers would rather have a single console that would play all their games, games that won't come to their consoles.

It's not porting, it's basically emulation. The original game code runs on the PCE cpu as is (it's backwards compatible), except for the port writes and reads - those are patched (since they are 3bytes long, patched to JSRs to call emulation code). The PCE video isn't compatible *or* similar to the NES. The port for video read/writes is 16 bit and only takes WORD transfers to vram, the tilemaps are ~nothing~ alike (doesn't have four name tables like the nes and snes), different sprite system as well as layout, colors and subpalettes are completely different (there is no attribute ram or setup like the nes), sprite and tile cells are complete different planar format (from nes as well as each other), the sprite cells smallest size is 16x16 pixels (which means ~every~ sprite in the SAT has to be check and altered with X/Y offsets for H/V flipping), etc.

The audio is completely different too, but since it's tiny-pcm sample based, you can roughly emulate the nes sound. Volume doesn't directly transfer (linear VS log), the periods are all off, it doesn't have hardware volume envelopes or sweep units or note lengths, etc. The backend code emulates the PPU and APU on the fly and converts the data between the two systems as needed. It's only because the PCE is running 4x the speed, is that it's able to run the game logic in realtime and still be able to simulate the PPU and APU, and actually remove slowdown in the original game.


I wouldn't put the PCE in with NES and relative generation. It's too much of a leap. The tendency is to do so because of the 65x variant that the nes shares, but power of the machine is just out of the league of that generation (nes,sms,c64,7800,etc). It does share the inherent weakness of only one BG layer of the 8bit generation and stock hucards are limited to 8k ram (makes for weak compression schemes and no buffer/room for decompressed gfx/animation/etc to dynamically pool from). But despite having an 8bit cpu, its power is that of an early 16bit generation system - both graphically and processing power (faster than the snes, rivals the Genesis). This isn't nes generation: here, here, and here, Art of Fighting, Fatal Fury Special, World Heroes 2, Street Fighter 2, Lords of Thunder, DraculaX Rondo of Blood, etc. Also, there are two PC-engine systems; Original PC-Engine and PC-Engine Super Grafx (an upgraded PC-Engine, adds more vram, sprites per line, and another BG layer)

That's exactly the point though, Sega proved that it was possible to be successful despite Nintendo's policies, the argument was that the Turbogfx was hidered by them.

For the record, both systems launched at about the same time in the US, and retailers had assumed that NEC would completely crush Sega, to the point that Sega had a hard time convincing them to sell the system and when they did it was only until Christmas (well, until retailers saw how the systems actually performed). Look here:
http://www.sega-16.com/2008/03/interview-al-nilsen/

People have been able to do that for years. One benefit of Microsoft's monopoly is that a PC running Windows plays substantially all modern PC games. Since the late 1990s and through the end of the SDTV era, PC discrete video cards came with an S-Video output, which can be used with a TV as a monitor. And since 2007, TVs have supported the VGA and DVI signal formats that PCs had been producing for years. (HDMI is DVI-D in a different connector with audio in the blanking period.) So if you aren't specifically looking for Mario, Zelda, or Pokémon, why not just buy a PC for the living room and play all controller-friendly Steam games?

Because I want to play Metal Gear Solid 5™ and Grand Theft Auto 5™ as soon as they come out, without being spoiled of their story or gameplay until the PC version is made. There are also some games that are console exclusive such as Red Dead Redemption, and other miscellaneous games that are locked to either Sony and/or Microsoft consoles, but not Nintendo's.

Now I'm curious as to what other measures to avoid spoilers you consider practical. Do you also...

• Avoid reading reviews and buy games as they come out, poor quality be danged?
• Subscribe to all cable TV channels so that you can, say, watch Showtime and HBO original series as they air rather than months later once the DVD set of the season comes out?
• Stand in line for a day to buy a console on launch day so that launch titles' plots aren't spoiled for you by people who did manage to score a launch console?
• Move to the east coast of whatever country you live in so that games' plots aren't spoiled for you by people who got a copy at midnight on the east coast?
• Maintain homes in multiple countries so that plots of films, TV series, and games released first in another country aren't spoiled for you by people living in the work's country of origin?

Besides, other than RDR, what games are available on both PlayStation 3 and Xbox 360, or both PlayStation 4 and Xbox One, but not PC? I want ammo against some of the "PC master race" people who inhabit a couple other message boards.

I said it was part of why the TG16 failed. Never did I say it was the sole reason. Another reason I've read is that in Japan where the PC-Engine was very successful, NEC marketed the system in the bigger cities primarily. They thought they could do the same in the US by just marketing it primarily in the largest cities like New York. There are other reasons though like many games that were released for the PC-Engine did not get released on the TG16. Some may have been related to Nintendo policies. I'd have to double check but I think there are no US releases by Konami. Konami released Gradius, Gradius II, Salamander, and ofcouse Castlevania Dracula X on the PC-Engine. Also I think only 1 Sega title of a few on the PC-Engine got released here, Space Harrier I think.

tomaitheous's PC-Engine NES emulation library is really impressive. I can't think of anything else like it. I remember working with one version of it to try to get I think it was Contra running on the PCE. I recall getting it working but it didn't support 8x16 sprites which were needed.

Back to the topic, unlike the Sega Master System the PC-Engine should not be considered part of the same generation as the NES. The PC-Engine does belong with the "16-bit" generation of the SNES, Genesis, and I guess the NeoGeo can be thrown in with it too. There are lots of people that like to call it an 8-bit system as a negative remark or to group it with the NES. These people generally don't know much about how any of these machines work. If you look at the game library you can see it's way beyond the NES and SMS. If you just consider what it can do versus the NES it's also obvious that it is the next generation.

The TG16 is way beyond the NES, but it's also way behind the Genesis. What the 68000 has over the 65C02 are fast multiply and divide (needed for certain physics and 3D calculations) and 16- and 32-bit addition as primitives (same). And though both have equivalents of a DMA unit, only the Genesis has hardware for compositing two background layers. And more RAM allows for more destructibility in levels; the stock TG16 is down there with the SMS and the original Game Boy in this respect, and I don't think it was easy to fit extra work RAM in a HuCard. Finally, some game designs need a third trigger button, in addition to I and II or C and B for jump and standard attack, that isn't as hard to reach as Select.

I can't comment on cross-platform games for Sony and Microsoft, but if you want ammo against "PC master race" types, look no further than the dearth of JRPGs on the PC compared to just about any console (ever). Personally, JRPGs are pretty much the life and blood of my gaming experience. I know Ys and some FF games are on Steam, but no Star Ocean, no Tales of XYZ, no Dragon Quest, no Rune Factory, no Kingdom Hearts, no Disgaea, and the list goes on for perpetuity. I love the fact that MGS5 is coming to Steam, since I have no reason to buy any next-gen console atm. If Square, Bandai-Namco, NIS, and Atlus went PC for even a fraction of their games, that would be the one thing to sway me in favor of PCs, and this is coming from someone who was playing the NES before 1 year of age.

This. It's pretty much sandwiched between the 3rd and 4th generations (in the same way, the SG-1000 mark I and II was sandwiched between the 2nd and 3rd generations).

Also I'm not sure if it's not fair to count it as competition, because when it launched it was technically competition to the NES (even if late one). The Super Famicom wouldn't come out until three years later.


Yeah, but that seems to be slowly changing lately (albeit more from the hand of the smaller developers), so if that ends up panning out in the long term that argument won't work anymore. Also JRPGs really don't appeal that much to the West, so that also makes it kind of a pointless argument... you need to focus on AAA releases if you want to win any argument against fanboys.

It's not changing significantly though, and there's no guarantee it'll expand. The companies involved now might pull out if sales don't rival console sales or at least meet their own internal expectation. The last time I checked, Sony and Nintendo were still Japanese companies, and JRPGs make quite a mint over in Japan. It won't make or break the market, but It's not something (in financial terms at least) that can be ignored. On a western level, sure it's easy to dismiss it, but not necessarily in the overall view. At any rate, isn't arguing with internet fanboys pointless to begin with? Their denial of evidence is, at times, second to none.

For the sake of maintaining the original discussion, for what it's worth, Wikipedia at least claims that the fourth generation essentially began with the PCE. Every other credible source I've seen seems to agree on that, though I'm willing to see contradicting sources. It doesn't surprise me that the TG16 was behind the Genesis given that the Genesis was partly a response to both the NES and the TG16.

Arguing with Internet fanboys helps me discover my own hidden denial of evidence. Without arguing with iOS fanboys like BasilBrush and PlayStation fanboys like CronoCloud on Slashdot, I could never have written this essay about why someone would even think about choosing a console over a PC.


CronoCloud says people chose NES over C64 because C64 had too much of two things: 1. price, and 2. loading time.


By that measure, the third generation arguably started with the SG-1000 and the nearly identical ColecoVision and CreatiVision. I see CV as 2.5-gen, PCE as 3.5-gen, and 3DO, 32X, and Jaguar as 4.5-gen.

I've never heard of the CreatiVision, but research says it uses a 2MHz 6502. So how did that machine compare to the others, and the NES by extension?

As for consoles over PCs, your essay nails most of the points, but misses a critical one. Game availability. PC might have dozens of tower defense games on Steam, but consoles will get whatever game marketing has hyped up as being the second coming of Christ, which is any game from Konami, Rockstar, or Square-Enix. Those games will also not come to Nintendo consoles, and as a result Nintendo consoles are almost always supported by Nintendo's own games. The GameCube got Twin Snakes, a remake of dubious quality of a 6-year-old-game, but it was a drop in the bucket when the PS2 got MGS3 a few months later, a game many people wanted to play. No one bought a GameCube for a game they already played 6 years ago, but a lot of people bought a PS2 for MGS3, one of the most hyped games since San Andreas. To say third party games don't sell on Nintendo consoles is a lie, especially when all the evidence consists of games that appear as if they were deliberately trying to sabotage their sales.

I'm simply saying that with fanboys, it's hard to get anywhere, and all bets are off when it comes to having decent discourse. Getting into lengthy, irrational, impassioned "discussions" where the opposing side comes away as biased as before (or even more so) seems like something I'd want to avoid at any rate. It's certainly possible to meet fanboys that are well articulated and well-versed in what they believe, but those have been the minority in my experience, and ever so hard to find depending on the community and subject. I understand that talking about subjects when viewpoints differ helps strengthen your own position, certainly, yet arguing with some fanboys is a downright depressing experience. Perhaps this is just the cynicism I get when looking at sites like GameFAQs.



It's not like there are definitive dates and periods established by accredited Game Historians or something like that, so everyone's free to construct their own sub-generations like that. That's kind of how I see things btw, internally at least. On paper though, or when I'm communicating to other, I keep my generations rounded up

I tried to leave out points that were a wash. PCs get their own second coming mega-games, just from different publishers. Blizzard games come to PC first and often only. And if Valve ever managed to count to 3, it'd be on PC first. These are the games that cause people to turn an office PC with an Intel IGP into a gaming PC.

Anyway, for ColecoVision vs. CreatiVision, a 6502 clocked at f Hz is usually considered equivalent to a Z80 clocked at 2f Hz. So yes, a tie, except for marketing.

Well, to be fair, the SG-1000 was launched the same exact day the Famicom did (which is also part of why now it feels odd that Sega isn't in the console market but Nintendo is, they entered at the same time).

My experience is more from the GBC (not exactly a z80), but from what I've looked over of the z80 - there's still a lot of register loading and unloading over head. I mean, it's similar to the 68k in how you do more register-register operations, but it has quite a bit fewer of them. It seems crippling for its type of design. There were also some missing direct memory address modes that would have speed it up a bit. As far as easier to program for, maybe for beginners or new to the processor. But once you've gotten use to any of these processors - everything becomes easy. If you mean tedious, then that's something else. Some people find writing 65x code very tedious (the CLC/SEC, the Accumulator style arch, etc), but I find the same tedium in z80 code as well. The small amount of address registers on the z80, compared to the 65x, ~always~ annoyed me.

I did GBZ80 before I did 65x, and I found it (GBZ80) quite easy to learn right off the bat. When I jumped over to 65x... I though it was the weirdest thing I had ever seen (and I had done x86 assembly) But that lasted all about a month, then it was like normal (as you can get for assembly). I did 68k after that, and it was breeze. I did v810 and PIC16xxx after that. 16xxx was a wake up call - thee worse ISA I'd ever seen. I decided never to complain about processor ISAs again. There's NO stack on that thing. Doing function calls is tricky. It can nest two or three of them max, outside of that you have to do a software stack - but the memory access and banking system make this a real pain in the ass to do. Certain logic is missing (flags and such) and so you have to write all this extra code to give back that functionality. And I don't mean just a few instructions either ;>_>

tepples, when I was professionally involved in this, the canonical answer to why most publishers preferred to release on consoles, or at least release first on consoles, was piracy on the PC.

While it's much more likely for piracy to happen on PC than on consoles, isn't it still rather uncommon? Then again, I don't expect PC game sales to be particularly high, if anything, most non-Valve game sales seem to be rather balanced across the board. So the piracy ratio would be rather high given how few people actually buy games. Non-Nintendo consoles are fairly similar, but they have higher emphasis on the most hyped game of the month instead. Nintendo consoles are barren wastelands, and when they do get third party games, they get hilariously delayed non-canon spinoffs with a chibi art-style that plays nothing like the series it is named after, alienating fans to the point of no one but people who own Nintendo consoles being interested in their games. And if by some twisted twist of fate those games do sell well, that means nothing to the publisher.

Piracy is incredibly common. I find it odd that you'd suggest otherwise here, on an NES emulation website. It is extremely common on PC. Less common on consoles, for various reasons. In recent years, the proliferation of online leaderboards has been a huge source of statistics on just how many people pirate games. Example: http://2dboy.com/2008/11/13/90/

The piracy statement is not my rationale, it's the one I most commonly heard from publishers. The second most common thing said was that they expect poorer sales from a PC release, though the piracy problem is considered part of the problem in sales, in this rationale.

I'm not so sure that it's "way behind". PC-Engine did not support two background layers however it did support an impressive amount of sprite coverage. Some of the more impressive games manage to give the appearance of more than one layer quite well.

Now the SuperGrafx is closer to the Genesis. Sadly it didn't catch on but it did support two background layers and even more sprites on screen and per scanline. Still not as much cpu available RAM as the Genesis at 32KB, but a significant improvement over 8KB. If it had managed to catch on and take over the regular PC-Engine's rein it would have been impressive when mixed with the successful CD-ROM in Japan. It wouldn't have worked so well for North America since it launched after the TG16 launched.

Oh and there are 3 button and 6 button controllers available for the TG16, just like the Genesis later had 6 button controllers available.

But I don't think there were a lot of games that required one. Games still had to be designed around the controller included with the console, just as games for phones have to be designed around touch control rather than, say, a MOGA.

For the record, this is probably heavily in part due to DRM being built into the console itself (say whatever you want, the CIC chip is technically hardware-based DRM). This is notorious within the NES itself: the NES didn't really see much piracy, but the Famicom was piracy heaven, to the point even the system itself got cloned.


The problem is, the sprite count is comparable to that of the Mega Drive and the SNES, so that isn't an advantage for it either.

I was just gonna mention the NES' 10NES chip. That was a very effective method of anti-piracy that was difficult for pirates to circumvent. To this day, no one has deciphered how the chip actually works, and the CIC chip used in repros is allegedly a clone of Atari's Rabbit chip, itself a clone of the 10NES. That said, it can be easily bypassed by modifying your console, and some companies used voltage spikes to temporarily knock it out. It was a very effective form of DRM that was also not very invasive.

Wrong: http://hackmii.com/2010/01/the-weird-and-wonderful-cic/

Despite that, many clone CICs out there are indeed clones of Tengen's clone. There's no allegation, there's a thread about the chip's reverse engineering efforts on this very forum.

Huh, I could've sworn that a thread here mentioned that, no matter how hard they tried, they couldn't find a pattern, and by extension they couldn't replicate it. Did other consoles of the time use lockout? I believe the SMS and 7800 had software based lockout, where they had to look for a string in the code. I find it ironic Nintendo didn't use a 10NES in the GB and instead opted for a in-code lockout. Then again, they probably had to save space.

Argument for the PC master race: http://www.polygon.com/2014/9/8/6120417/dark-souls-rock-band-guitar-controller

Genesis, Game Boy, and Game Boy Advance require games to contain a valid header with the console maker's name as text (Genesis) or image (GB, GBA). This "Trademark Security System" (TMSS) was ruled ineffective in the USA in Sega v. Accolade. Atari 7800 games are flat-out digitally signed, something other companies' consoles wouldn't widely adopt until Xbox. Patent issues?

rainwarrior: You have a point about accessibility. For people who can't work a standard controller, it's easier to build a custom controller for a PC game. But then this breaks when a game uses XInput, which works only with Xbox 360 controllers (and with Xbox One controllers since a recent Windows update). All Windows Store games that use a gamepad use XInput, and all Windows RT games are Windows Store games. Therefore, at least for the purpose of controller accessibility, we can lump Windows RT with Xbox 360.

Not sure on the amount that required said gamepads, but the 3 button pad is just the same as the Genesis (the 'select' button is moved over next to the action buttons). Quite a few games were setup to use select in it probably would on the Genesis (quick select/option button).

Some later games used the extra buttons of the 6 button pad, if it was detected. But it was mostly for quick item switching and such (a minor convenience).



As for the SGX, I'd put it above the Genesis (though not by a lot). It has twice the vram (128k), it has a combined 512 sprite pixels per scanline, combined 128 SAT entries, having two BG layers make the 16 of the 32 subpalettes just for BG layers even more usable/capable. The window registers (a priority mixing chip) allows for allows for complex graphic tricks and transparency shapes. The SGX has the same res modes as the PCE, but making the higher 7.16mhz and 10.74mhz dot clock pixels modes incredibly useful because the heavy sprite scanline pixel bandwidth to back it up. Both res modes are higher than the Genesis. The audio is still the same, but the SGX has a new revision of the audio chip which allows switching on/off channels without 'blips' - allowing you use each of the six channels 32 byte buffer as a PCM sample play back buffer (a 1khz timer routine can do 32khz stream streaming). I had demos up and running in no time doing this - I wonder if dev's would have eventually done this as well. The original audio chip can do this trick too, but you have to use/waste a spare channel to invert the blip (caused by sudden volume change), so it's more practical on the SGX. The Genesis still as a few nice tricks to its own in comparison, but overall all I'd take practical features (vram, sprite bandwidth,etc) over specific case special effects (shadow/highlight, column scrolling, etc).

At that first video you posted, I see the game doing some screen warbling effect. Could the NES do something similar? I know Kickle Cublicle does something similar.

Yeah, and more extreme too (see: road deformation in racing games). It's basically just linescrolling.

What part of Kickle Cubicle?

The sine wave animation? That's just to show that the transparency parts/transitions/edges aren't limited to just straight edges or lines. The hblur effect is to show that it can enabled for just the transparency part (making the light areas fuzzy; aka poorman's glow) - though not for the sprite (only BG areas). The two videos approach the transparency effects in different ways (and have their own advantages/disadvantages). But yeah, both are H-int effects (common called 'linescroll' effects). They can be done on the NES with an external interrupt+timer (or line reader like the mmc3 does IIRC). So they can be done on the nes, and full screen like that, but you'll be cutting into your already limited cpu resource. You're looking at 224-240 interrupts per frame, so multiply that with the amount of cycles the routine takes. Plus you have setup/prep time that you need to add to that (usually a table). On the NES, I'd probably do it every two lines and apply the savings for something else.

There's a third video, but it's nothing special that other systems can't already do (other than it's more practical to do since there's a lot of sprite bandwidth per line than they other systems). Both Genesis and PCE can do it, and I believe a couple of games do this trick on both systems. And if I have my fact straight, that trick can also be done on the NES. But the limited sprite bandwidth makes it near impractical do in application on the nes. And, IIRC, you can't do this on the SMS because the BG selects the priority of the sprite instead of the sprite table entry itself (someone correct me if I'm wrong here).

On that note, do any official NES games do that trick (sprite priority->BG trick)? I mean for transparency/silhouette (and not for popping a piece of the BG over the sprite in dynamic areas).

https://www.youtube.com/watch?v=VIOo3DZRPWk at 14:23

According to the same game, there's also a scene where the sea is parted (vertically) to reveal a castle underwater. I never knew the NES could split backgrounds vertically and scroll them, unless they simply redrew the BG tiles and used sprites to make it look as if it's a transition.

Another good example of sine wave line-scrolling effect is the title screen of the Japanese version of Fantasy Zone on the Famicom.