I was surfing around when I suddenly realized how similar the SMS is to the NES. They have about the same hardware capabilities (screen resolution, colors, etc.)
But which one is better than the other?
Technically speaking, I have a feeling that it's SMS, but I'm not sure. Anyway, when it comes to programming, NES just _have_ to be easier to program for. The Z80 is just a huge mess.
But what's your opinion?
Jaffe wrote:
I was surfing around when I suddenly realized how similar the SMS is to the NES. They have about the same hardware capabilities (screen resolution, colors, etc.)
I wouldn't say they are similar in those areas.
Resolution on the NES is 256x240, while SMS has 256x192 pixels. This makes the SMS image perfectly fit the 4:3 ratio (i.e. it has square pixels) while the NES outputs images that are somewhat stretched.
About the colors, this must be the biggest difference between them! Colors on the NES are defined in some sort of HSL variant, while the SMS uses 6-bit RGB values. Both can generate 64 colors, although not the same 64, and some of those are just black on the NES.
Also, the NES has 8 palettes of 4 colors each, and each tile can use only 4 colors. The SMS has 2 palettes of 16 colors! Each tile can use up to 16 colors! This is a major advantage over the NES. It can produce much nicer graphics. I'm not saying it always does, but it can.
Quote:
But which one is better than the other?
Technically speaking, I have a feeling that it's SMS, but I'm not sure.
Technically, the SMS is clearly superior. The only disadvantges I can think of is that the SMS can't mirror sprites (although it can mirror background tiles). I guess that the lack of choice between VRAM and VROM could be a disadvantage too, but not a very big one.
Also, since color depth is much better on the SMS, there is not enough room for all 512 tiles that could be addressed, I believe it only uses 448.
However, the SMS allows you to decide how to use VRAM, and you have some control over where things like patterns and name tables are stored in VRAM, allowing for some nice tricks.
Quote:
Anyway, when it comes to programming, NES just _have_ to be easier to program for. The Z80 is just a huge mess.
But what's your opinion?
I never actually progammed the SMS, but I want to sometime soon. From what I've read, it doesn't sem any harder than programming the NES, just different.
There are only a few memory mappers for the SMS so this is already much simpler than with the NES. I read that it's easier to set up scanline interrupts in it too.
Graphically, I'd think it's easier to work with the background on the SMS. There is no need to work with complicated attribute tables (one of the biggest flaws on the NES, IMO). Also, the SMS seem to be able to work much faster with video. In games such as Street Fighter or Mortal Kombat, it is able to draw huge "software sprites", meaning it can update a huge ammount of tiles in little time.
I think the Z80 is a nice processor. Along with the 6502, they are the cooles processors I've ever studied! =)
I like both system, a lot, but I have to say that the SMS is technically superior. The problem is that it doesn't have that many good games, the NES library is much bigger and better. I think there were legal issues at the time, that didn't allow companies that made games for Nintendo to make them for Sega too. And having to choose, of course they pick the most popular system. I think that's what killed the SMS.
Yeah, no quirky attribute tables is really a big advantage on the SMS. But do you really mean what you said about Z80? I think it's a big mess, with lots of unlogical register combinations and adressing modes. It may all come to sense if you learn to use it properly, but it seems quite strange to me :/
EDIT: And, also, I think SMS can display 256*224 and 256*240 (PAL only) too.
Jaffe wrote:
But do you really mean what you said about Z80? I think it's a big mess, with lots of unlogical register combinations and adressing modes.
I used to think so too. And as long as you try to code 6502-styled programs with it, it will still feel that way. But once you get used to how it's supposed to work, it is a very powerful processor.
It has instructions for looping, a second set of registers and other things that are supposed to make programming easier, and maybe it does. It has a lot of registers (when compared to the 6502), so you can have register-oriented logic, instead of memory-oriented like in the 6502.
I think it is a nice processor, but you have to get used to it, as it's very different to the 6502 when it comes to programming style.
Quote:
It may all come to sense if you learn to use it properly, but it seems quite strange to me :/
I'm much more fluent in 6502 (actually, not at all with the Z80) assembly, and I'm pretty sure I can't use the Z80 properly yet either. I learned assembly with the 6502, so it may be a bit hard for me to get used to anything else, but I don't think it's impossible! =)
Quote:
EDIT: And, also, I think SMS can display 256*224 and 256*240 (PAL only) too.
I'm not sure about that, but I know that in NTSC, the internal size of the "name table" (I don't think they call it that) is 256x224 pixels (32x28 tiles), but I don't know if you can display it all. Maybe you even can, but most games don't because of scrolling. I wouldn't know about PAL.
tokumaru wrote:
Resolution on the NES is 256x240, while SMS has 256x192 pixels.
As tokumaru pointed out, SMS also has a 256x224 pixel mode.
Quote:
This makes the SMS image perfectly fit the 4:3 ratio (i.e. it has square pixels)
O RLY? Can you give a citation for this?
There are 227.5 periods of the NTSC color subcarrier in a
standard scanline (consoles of the day deviated from this by +/- 1), roughly 186 of these being within the visible or overscan (not horizontal blanking) region. The earliest consoles (e.g. Atari 2600) generated one pixel for each of these periods (or 1.720:1); an NES pixel is 2/3 of these periods (or 1.147:1). In order to make square pixels with 240 lines, a picture generator would have to make 320 pixels over 186 color periods, or one pixel per 0.581 periods. A ratio of 7 color cycles per 12 pixels would be almost perfect; is this what the SMS used?
Quote:
Also, the NES has 8 palettes of 4 colors each, and each tile can use only 4 colors. The SMS has 2 palettes of 16 colors! Each tile can use up to 16 colors! This is a major advantage over the NES. It can produce much nicer graphics.
Drawbacks of the SMS video chip:
- These nicer graphics take more ROM space.
- Palette swaps (e.g. Balloon Fight; Mario Bros.) are done in software and take more VRAM space.
- Tile animation (e.g. Super Mario Bros. 3 [?] blocks) is always done in software.
- Because the SMS/Game Gear sprite hardware does not support vertical or horizontal flipping, sprite cels must be flipped in software or stored twice in the ROM.
Quote:
Also, the SMS seem to be able to work much faster with video. In games such as Street Fighter or Mortal Kombat, it is able to draw huge "software sprites", meaning it can update a huge ammount of tiles in little time.
If an NES game to have fifty extra lines of vblank time like the SMS has when run in 256x192 mode, it could do exactly the same thing, right?
Quote:
I think there were legal issues at the time, that didn't allow companies that made games for Nintendo to make them for Sega too.
And Nintendo got fined for this practice in antitrust court.
tokumaru wrote:
I think it is a nice processor, but you have to get used to it, as it's very different to the 6502 when it comes to programming style.
Do these differences have anything to do with the C64 vs. Spectrum wars?
The SMS does 32 colors, not 64. Two 16 color palettes. Background tiles can select either palette, sprites can select only the second palette. The background color is not shared among the two palettes. You can also do raster effects to change the palette, Sonic 1 does this for a water-level in the Labyrinth Zone.
As for graphics capabilities comparison, it's actually a mixed bag. The NES's 2-bit graphics are clearly inferior to the SMS's 4-bit graphics, but 2-bit tiles take up far less space than 4-bit tiles. So graphics for the SMS take up much more space in the ROM. You also need to either do software sprite flipping, or store reversed versions of the tiles in rom. Many SMS games also didn't take advantage of the large color depth, and only used very few colors per tile, but that's not the fault of the system.
Since the chr memory can not be mapped into the cartridge slot, the SMS could never do tile animation to the extent seen in Gremlins 2 or Return of the Joker.
Sound-wise, the NES wins by far. The SMS can't select duty cycles for the square waves, and does not have a DMC channel. SMS/GG games sound almost the same, except for maybe a different melody each game. It's not like the NES where you can listen to the game music and immediately identify the company who made the game.
Personally, I love the Z80 and can't stand the 6502. But that tends to happen if you spend High School programming ASM games for your TI83.
tepples wrote:
Quote:
This makes the SMS image perfectly fit the 4:3 ratio (i.e. it has square pixels)
O RLY? Can you give a citation for this?
I knew someone would complain about that! =) I see what you said there (although I don't understand it all). Maybe it doesn't have square pixels after all. I guess that the fact that it's resolution has the same ratio than a TV doesn't mean it has square pixels. I went ahead of myself by saying that, sorry.
Quote:
Drawbacks of the SMS video chip:
- These nicer graphics take more ROM space.
As I said, you end up with less than 512 tiles.
Quote:
Palette swaps (e.g. Balloon Fight; Mario Bros.) are done in software and take more VRAM space.Yeah, you can't have a blue enemy and a red enemy share the same patterns as you can on the NES.
Quote:
Tile animation (e.g. Super Mario Bros. 3 [?] blocks) is always done in software.Yes, this is the problem of not having VROM.
Quote:
Because the SMS/Game Gear sprite hardware does not support vertical or horizontal flipping, sprite cels must be flipped in software or stored twice in the ROM. In the end this ends up stealing you a lot of tiles. What were they thinking when they didn't include sprite flipping?!?
Quote:
If an NES game to have fifty extra lines of vblank time like the SMS has when run in 256x192 mode, it could do exactly the same thing, right?
Yes, it could. The hard part would be to pick a 4-color palette that could represent nicely a background and two fighters. =)
Quote:
And Nintendo got fined for this practice in antitrust court.
Too late for the SMS I guess...
Quote:
Do these differences have anything to do with the C64 vs. Spectrum wars?
I wouldn't know. IMO, Spectrum will always loose because of crappy graphics.
Dwedit wrote:
The SMS does 32 colors, not 64. Two 16 color palettes.
I meant 64 colors to pick from. I know it can have 32 in use at a time, but those can be chosen from a total of 64 colors, like on the NES. The Game Gear can pick from 4096, I think.
Wow, the VDP documentation I'm reading says it has hardware support for scaling sprites. That sounds kinda neat!
Jaffe wrote:
Wow, the VDP documentation I'm reading says it has hardware support for scaling sprites. That sounds kinda neat!
Not really. It can scale the sprites, but only to twice their size. And you can't even apply this transformation to individual sprites, it's either all or none of them.
This makes this scaling kinda useless. If you could apply that to individual sprites, you could make huge bosses or things like that. But as it is, if you try that you'll scale the player also, and then there is no point.
Dwedit wrote:
Personally, I love the Z80 and can't stand the 6502. But that tends to happen if you spend High School programming ASM games for your TI83.
Really ? I trough those TI calculators had a 6800 CPU in them ? At least I've the TI V200, but I've never programmed it unfortunately, because it has so much features and the manual is confusing. I just use it for standard algebra and all.
I know nothing about the SMS, but it sems like Sega did everything to get their machine technically supperior to the NES, while maitaining useless features all the way along. One single sprite palette is stupid, because regardless of how many colors you get in it, that means that you have to keep that same palette all the game along, and that all object will look the same everywhere (or just limit your objects to 2 bits and code software decoding to 4-bit and palette-region swapping, supporting 5 palettes overall).
Sprite strecthing sound ridiculous as Tokumaru stated it, being totally useless, unless for some cutscenes maybe if you're lazy and want to get pixelised stuff on screen.
Sprite flipping is necessary to all platform games, wich was the dominant genre back then. Unless you make your game have so much detail that monsters aren't just mirrored from left to right, you could do flipping in software and dynamicly upload the pattern table if the console allow so (at least the NES don't, but maybe the SMS does).
In that case VRAM is much more powerfull than VROM anyway, the only advantage VROM has in the NES is if you want to switch it fastly, and if you're just too lazy to make your own pattern-table writing code in quick NROM demos.
I'm pretty sure that SMS pixels are the same size as NES pixels, not square. In determining this size, all that matters is how long each pixel lasts in the video signal; vertical resolution is irrelevant as a scanline is always a scanline, regardless of how many are black at the bottom of the screen. Likewise, the ratio of the width to height (in pixels) of the active video area has no relation to the ratio of the width to height of a single pixel.
The advantages I can think of that the NES has over the SMS are:
* Better support for hardware expansion (i.e. the sound-in pins on the Famicom)
* A significantly nicer sound chip
* The 6502 (I agree that the Z80 is just confusing)
* Slightly nicer sprite handling (flipping support)
Other than that, the SMS is generally the nicer machine.
* A controller with more than two freaking buttons
* No really nasty pixel artifacts (you think they're bad on the NES; take a look at an SMS or even Sega Genesis some time, or the TI 99/4A which uses the same graphics chip, ugh)
blargg wrote:
* A controller with more than two freaking buttons
How many buttons does Famicom player 2 have? Famicom player 1 has select and start, but aren't those on the SMS console itself? And how does the player reach select and start while in the heat of action?
blargg wrote:
* No really nasty pixel artifacts (you think they're bad on the NES; take a look at an SMS or even Sega Genesis some time, or the TI 99/4A which uses the same graphics chip, ugh)
I have no idea what you're talking about here. I think both Sega systems have superior image quality when compared to the NES. I haven't played with my real SMS for a while though, but used the Genesis/Megadrive a couple of weeks ago. I can't see those artifacts you're talking about.
tepples wrote:
blargg wrote:
* A controller with more than two freaking buttons
Famicom player 1 has select and start, but aren't those on the SMS console itself? And how does the player reach select and start while in the heat of action?
The SMS has a single "pause" (as opposed to start) button on the console itself. The controllers only have the directional pad and buttons 1 and 2. From a programming point of view, the pause button isn't even a button like all others, it actually triggers an NMI.
commodorejohn wrote:
The advantages I can think of that the NES has over the SMS are:
* Better support for hardware expansion (i.e. the sound-in pins on the Famicom)
* A significantly nicer sound chip
* The 6502 (I agree that the Z80 is just confusing)
* Slightly nicer sprite handling (flipping support)
Other than that, the SMS is generally the nicer machine.
1. Useless to us in the west.
3. Purely a matter of opinion. Once you get used to the Z80, it's not that bad, and it's much more powerful.
tepples wrote:
How many buttons does Famicom player 2 have?
What does strcmp( "NES", "Famicom" ) return? NES controllers have four buttons: A, B, select, and start. Both players have these, and they are useful during game play and used more often than you'd want to get up and reach to a "pause" button on the game console itself.
tokumaru wrote:
I have no idea what you're talking about here. I think both Sega systems have superior image quality when compared to the NES.
Then you aren't looking close enough (or maybe PAL versions don't do this and you're using that). Both the SMS and Genesis don't vary the colorburst phase each scanline, resulting in really ugly vertical artifacts based on the horizontal position of an object. Anything scrolling in the background will get thick and thin, blurry and sharper, depending on where it's scrolled. It always disgusted me, especially that they didn't fix it on the Genesis.
blargg wrote:
Then you aren't looking close enough (or maybe PAL versions don't do this and you're using that).
My systems are PAL-M. I really don't know how all this colorburst thing works in PAL-M.
Quote:
Both the SMS and Genesis don't vary the colorburst phase each scanline, resulting in really ugly vertical artifacts based on the horizontal position of an object. Anything scrolling in the background will get thick and thin, blurry and sharper, depending on where it's scrolled. It always disgusted me, especially that they didn't fix it on the Genesis.
OK, I might have seen that on the SMS, but just doesn't ring a bell for the Genesis. I have also seen that on my MSX machines, and the SMS video chip is a direct evolution to the MSX VDP. And as I've heard, the Genesis VDP is an evolution of the SMS VDP (although it lacks the screen modes that were avaliable on the MSX, I think). That may be the reason this problem you talked about lived for so long.
blargg wrote:
tepples wrote:
How many buttons does Famicom player 2 have?
What does strcmp( "NES", "Famicom" ) return? NES controllers have four buttons: A, B, select, and start. Both players have these, and they are useful during game play and used more often than you'd want to get up and reach to a "pause" button on the game console itself.
Would Nintendo's lot check reject an NES game if it didn't also run on a Famicom? The only commercial NES games I saw that used player 2's select and start buttons were unlicensed games.
Quote:
Both the SMS and Genesis don't vary the colorburst phase each scanline, resulting in really ugly vertical artifacts based on the horizontal position of an object. Anything scrolling in the background will get thick and thin, blurry and sharper, depending on where it's scrolled. It always disgusted me, especially that they didn't fix it on the Genesis.
But at least on the Genesis, you have exactly 2 pixels per color cycle, which makes the issue easier to pixel around.
Most games I think we've played here were in single-player mode, and the start and select buttons have been a significant benefit. But whatever, there's no point in debating this, as you've either played SMS games and had to keep reaching for the console, or you're just theorizing.
tepples wrote:
But at least on the Genesis, you have exactly 2 pixels per color cycle, which makes the issue easier to pixel around.
I calculated 1.875 pixels per color clock (6.7116375 MHz pixel rate, derived from 53.6931 MHz master clock), and the artifact pattern matches this. It's a bit more than the SMS (1.5 pixels per color clock, like the NES), but still gives nasty artifacts.
Ooh, here's a nice and interesting topic. Some various comments:
The NES has more shades of grey than the SMS. (Bonus!)
The SMS cannot change vertical scrolling mid-frame, as the NES can (with some effort), so some types of raster effects are impossible. Horizontal scroll raster effects are possible, though the method of setting up raster interrupts is pretty stupid. You can't set an interrupt to an arbitrary scanline (as on the SNES or PC-E), but rather set up an interrupt N scanlines after the previous interrupt. It's a bit convoluted.
Yeah, most SMS programmers who have commented on sprites have said that whoever decided that sprites could not be flipped should be flogged with a large wet fish, or something similar.
Sprite scaling on the SMS is useful sometimes... like at the bottom of the screen if you want a large status bar made of sprites. This is what Earthworm Jim on the GG/SMS does. You can keep sprites normal-sized until you get near the bottom of the screen, then turn scaling on.
Since the SMS uses VRAM, storing all the frames of a character's animation in VRAM at the same time is a waste of the system's memory. That's probably why many games have 4 or 8 tiles in VRAM that the Vblank code writes CHR data into to animate the main character, and -- yes -- flip his/her sprite data.
The lack of buttons on the controller and strange palette/sprite limitations are probably a result of being chained to the legacy TMSxxxx modes of the SMS' predecessor, the SG-1000.
The Z80 is a bit weird, but it has some nice and useful instructions that the 6502 doesn't, but apparently the Z80 is 4 times slower as a result. That's why Z80 programmers don't count clock cycles, but T-states, or something like that.
Finally, regarding the colourburst issue of NES vs. SMS, what Blargg wrote is true: the NTSC SMS has a terrible video encoder. Here, I'm working on a page that compares systems' RGB output to their composite outputs:
http://www.disgruntleddesigner.com/chrisc/gotRGB/screenshots.html
blargg wrote:
Most games I think we've played here were in single-player mode, and the start and select buttons have been a significant benefit. But whatever, there's no point in debating this, as you've either played SMS games and had to keep reaching for the console, or you're just theorizing.
I only had a Game Gear, which uses
mostly the same architecture as the SMS. Its start button was placed roughly where X is on a Super NES controller.
ccovell wrote:
You can't set an interrupt to an arbitrary scanline (as on the SNES or PC-E), but rather set up an interrupt N scanlines after the previous interrupt.
Doesn't the MMC3 work almost the same way?
On the topic of Gamegear vs. SMS, I haven't noticed the reputed horrible video quality of the SMS on my GG. (It's still not that awesome, but it's not anywhere near as bad as the screenshots Chris posted.)
Those comparison screenshots aren't consistent enough for comparison. A better way to compare video quality would be to take video snapshots with a good video digitizer accepting composite and RGB (or at least S-Video). Pointing a camera at a TV adds too much distortion (brightness, Moire effects, blurryness) and variation between different photos. You'd also need to merge even and odd fields to get a representative image, otherwise you're making the artifacts more prominent than they appear on a TV.
It seems like the NES CPU would be a little faster (lots of people compare a 4Mhz Z80 to a 1Mhz 6502), but the architectures are radically different and I don't know Z80 asm so it's hard to tell. It's probably pretty close, with each CPU being close to stomping the other at certain tasks (assuming a fully competent programmer on both sides, regarding that though I think the 6502 looks easier to learn and use fully since it's mostly about optimal use of addressing modes).
NES definitely has better sound. It can produce all kinds of textures, especially when you get the DPCM channel involved. SMS does have the advantage of having 3 melodic channels with volume control, but that's kinda overshadowed to me when the NES can go a whole 2 octaves lower for bass.
Being able to flip BG tiles seems kinda nice (SNES can do that), if not terrible useful, but there's no way I'd take that over being able to flip sprite tiles.. that's just pure crazyness.
Having the extra buttons on the NES controller sure is good too. Pause button on the console is kinda brain-dead, but a lot better than nothing I guess. Atari systems were kinda similar, but had more buttons and switches on the console than on the controller itself, heheh. Much to my confusion, you had to use those to play a few games too.
Having all those colors for tiles is pretty nice, but I bet that gets a little burdensome when it comes to having to redraw the sprites to flip them.
After writing Z80 asm for a couple of years, i'll add some of my characteristically useless comments to the matter:
+ 6502 has much more powerful methods of addressing memory
+ Z80 has a much more orthogonal instruction set
+ Z80 allows you to treat 8-bit register pairs, like B and C, as 16-bit units (BC), which is very cool
+ Z80 has some very cool auto-increment modifiers: ld A,[HLI] loads a byte from memory and increments the 16-bit pointer in the HL pair
- 6502 is missing lots of useful instructions, like INA/DEA, and passing everything through the accumulator is a pain in the ass.
- 6502 has 1 general purpose register. implementing any algorithm that accesses several variables ends up requiring more code compared to z80
- Z80 probably runs slower, and probably costs more to make, due to the increased complexity of the opcode set
I only used the GB/GBC castrated version of the Z80 (which is actually more like an Intel 8080), which is missing quite a bit of Z80 functionality, and i admittedly have done about 100 times more GBC programming than NES programming, but i would have to say i enjoyed the z80 more. Though when i moved to the ARM7, which clearly modeled its THUMB instruction set after the 6502, it was nice to have had experience working with the NES CPU.
Edit: INX/INY->INA/DEA
baisoku wrote:
- 6502 is missing lots of useful instructions, like INX, INY.
Umm, that's probably a really bad example since the 6502
does have instructions INX and INY (as well as DEX and DEY) - perhaps you were thinking of some other operation?
Well, the 65C02 can be had new from WDC for $5. Zilog doesn't seem to put prices on their site, but I believe the Z80 in a vanilla-processor version goes for ~$7.
Also, yes, the 6502 does have INY and INX (and DEY and DEX.) Amusingly, it doesn't have INC A or DEC A (though I believe the C02 adds this.)
I admit, though, that it's nicer to have more general-purpose registers as the Z80 does, and the 16-bit operations are a nice bonus as well. However, the 6502 has a clear edge on the Z80 in terms of execution times. Memblers is probably right, it probably depends on what's being done and who's doing it, but my preference leans towards 6502.
I think he means INA and DEA wich happen to be somewhat lacking sometimes. But just do clc / adc #$01 and sec / sbc #$01 pair to get the same results, wasting 2 bytes and 2 cycles.
I don't think the 6502 lacks anything actually. I've never tried Z80, but with all processors I've coded for, the 6502 has by far the best instruciton set. Many processor just have direct and indirect modes. Indexed, and indirect-indexed mode are pure genius, and you cannot see at wich points they makes the programmers live easier until you code for another processor.
Also X and Y can serve as general purpose registers, tough you cannot do any arithmetic on them exept increment and decrement (thanks god to read/write arrays), and you cannot for example directly add them with A wich would make the 6502 instruction set even more perfect than what it is.
Yes, it could be better (and in the 65816 incarnation, it is =) but it's still my favorite.
Bregalad wrote:
I think he means INA and DEA wich happen to be somewhat lacking sometimes.
Yeah, that's what i meant, sorry.
Bregalad wrote:
I don't think the 6502 lacks anything actually. I've never tried Z80, but with all processors I've coded for, the 6502 has by far the best instruciton set.
Every processor is missing something compared to something else. My comments were in no way intended to show A is better than B, just some strengths and weaknesses, from a programmer's perspective. You could write the same quality game for the NES if it were wired with a Z80 or a 6502. You'd just do things differently.
Bregalad wrote:
Also X and Y can serve as general purpose registers, tough you cannot do any arithmetic on them exept increment and decrement (thanks god to read/write arrays), and you cannot for example directly add them with A wich would make the 6502 instruction set even more perfect than what it is.
I argue that "general purpose" doesn't come with so many restrictions.
Bregalad wrote:
I think he means INA and DEA wich happen to be somewhat lacking sometimes. But just do clc / adc #$01 and sec / sbc #$01 pair to get the same results, wasting 2 bytes and 2 cycles.
Actually, each of those would waste 3 bytes and 4 cycles.
blargg wrote:
Those comparison screenshots aren't consistent enough for comparison. A better way to compare video quality would be to take video snapshots with a good video digitizer accepting composite and RGB (or at least S-Video). Pointing a camera at a TV adds too much distortion (brightness, Moire effects, blurryness) and variation between different photos. You'd also need to merge even and odd fields to get a representative image, otherwise you're making the artifacts more prominent than they appear on a TV.
Dear Sir,
I am quite intrigued with your proposition, and I agree fully with your point above. Please ship me one of your video digitizers.
Sincerely yours,
Christopher Covell, Esq.
seriously, though... your last point about merging even and odd fields doesn't hold water with the SMS, MD, or Neo-Geo, because the artifacting doesn't
change between fields, which was exactly my point.
Quietust wrote:
Actually, each of those would waste 3 bytes and 4 cycles.
I meant *additionnal* cycles as opposed to a simple DEA and INA (assuming they take the same number of cycles that the similar opperation on X and Y regs).
So yeah, I meant 2 additional cycles and 2 additional bytes.
This discussion is biased on an NES forum, and obviously also on an SMS forum:
http://www.smspower.org/forums/viewtopic.php?t=6955
As for my opinion, comparing SMS to NES is like comparing apples to oranges, they're too different (but in the same generation) to be able to factually tell which one is better. Many SMS games are technically impossible on an non-MMC5 NES, while many stock NES games are technically impossible on the SMS.
On the non technical part, if I had to choose between an NES with SMB3, Castlevania 3, Megaman 3, or an SMS with Sonic, Wonderboy 3, Alex Kidd in Miracle World, I wouldn't be able to make up my mind.
Note that Sega really missed their chance to compete against the worst flaw of the NES : They could have allowed MORE sprites on the screen (typically 128 sprites in total and 16 per scanline would be a pretty good start). But C.Cowell states that it is just like the NES, wich is lazy.
And the guy that compares SMS screenshot to NES screenshots claims the SMS is clearly supperior, while I don't see any significant differences between the quality of SMS graphics and NES graphics. Also, screenshots don't show much, graphics are a lot about animation. It's just like Sony wich show screenshots of pre-rendered cutsces of PS2/3 games before the release of the console and say "yah, our graphics will look like that".
Also, I really like working with luminance/chromance instead of RGB. The day I'll code a game wich uses RGB, I'll do everything trough a conversion from luminance/chromance values. This allow linear fade in and fade out easier to do (add/substract instead of multiply/divide), and make palette swap easier to do (keep the same luminance levels but change the chromance). Additionally, it allows cool effects if you change the chromance quickly (like in FF1 when you enter in the menu).
Bregalad wrote:
Note that Sega really missed their chance to compete against the worst flaw of the NES : They could have allowed MORE sprites on the screen (typically 128 sprites in total and 16 per scanline would be a pretty good start). But C.Cowell states that it is just like the NES, wich is lazy.
True about the SMS, but Genesis does what Nintendon't: 80 sprites, 20 sprites per scanline, 320 sprite pixels per scanline, sprites up to 32px by 32px.
tepples wrote:
True about the SMS, but Genesis does what Nintendon't
But that was expected, since the Genesis/Megadrive belongs to the following generation! If they hadn't improved that, Sega would have died much earlier! =)
About the screenshots comparing the NES and the SMS, I think they say something. They show that no system is clearly superior to the other. Some games look much better on the SMS, while other look much better on the NES.
The system where games run on is just a part of what makes them. There are many other aspects that will define the final quality of a game. The talent of the people who make it will define how well the platform is used.
I, for example, know nothing about the PS3. Even if I'm presented with the most expensive development kit, I won't be able to make anything good for it. I'd probably make a much better NES game!
What I mean is that both systems have advantages and disadvantages (and that will be true even if you compare systems from different generations), but the true quality of the games is defined by the people who make them. Even if you have good programmers/artists/musicians/whatever, if they do a half-assed job, it won't be good.
I really think that talent and effort are more important than the system itself. Realistically, of course... It's a bit unfair to compare a NES and a PS3, but you get the point.
Since Famicom was released nearly simultaneously with the Sega SG-1000, it would be most fair to compare those two systems. (Not that I agree with most of the arguments at SMS Power and am whining) IMO it's Sega's own fault that FC holds a candle to the MK-III. It's also Sega's fault for focusing their software efforts on poor inhouse arcade ports and not more Phantasy Stars or even Psycho Foxes.
baisoku wrote:
+ Z80 has some very cool auto-increment modifiers: ld A,[HLI] loads a byte from memory and increments the 16-bit pointer in the HL pair
The real Z80 does not have ld a,(hl+) instructions, only the gameboy has them. Instead, you'd use the block copy instructions, LDI or LDIR. LDI transfers (hl) to (de), increments hl and de, then decrements bc by one. It sets the overflow flag once BC =0. Alternatively, there's the LDIR instruction which repeatedly copies bytes and decreases BC until BC=0. Oddly enough, an unrolled loop of LDI instructions followed by a backwards jump is actually faster than the LDIR instruction.
There's also decrement versions, LDD and LDDR. And even Compare versions, like CPI, CPD, CPIR, CPDR, etc. But I usually use those instructions just to increment HL and decrement BC and set flags, the comparison is just an unused side effect.
kyuusaku wrote:
... more Phantasy Stars or even Psycho Foxes.
I love how SMS fans always use (at least) these two games (Phantasy Star
is great, though) as their systems' shining moments, when Psycho Fox was also released on the NES with another name, and both versions are pretty awful anyway, IMO.
Quote:
True about the SMS, but Genesis does what Nintendon't: 80 sprites, 20 sprites per scanline, 320 sprite pixels per scanline, sprites up to 32px by 32px.
The SNES have 128 sprites on screen, 256 sprite pixels per scanline, 34 convrted 8x8 sprites per scanline, and sprites up to 64x64 pixels. The only thing where the Genesis beats the SNES is the number of sprite per scanline, in all other points the SNES beats the Genesis (for sprites at least).
Quote:
The system where games run on is just a part of what makes them. There are many other aspects that will define the final quality of a game. The talent of the people who make it will define how well the platform is used.
I agree 100%.
Quote:
Even if you have good programmers/artists/musicians/whatever, if they do a half-assed job, it won't be good.
Play Castlevania II and you'll have the proof of that. (King's Knight is also a good example of this fact).
Bregalad wrote:
The only thing where the Genesis beats the SNES is the number of sprite per scanline, in all other points the SNES beats the Genesis (for sprites at least).
But even then I don't know if one system really "beats" the other, as in the end, both systems are able to display sprites all the way across the screen. Although the Genesis also has a video mode that's 256 pixels wide, but I don't know if you can still display the same ammount of sprites, then, in this case, the Genesis would be better than the SNES when it comes to the maximum number of sprites per scanline.
AFAIK, SNES graphics kick Genesis graphics butt. SNES has more colors, built-in rotation, transparency and all sorts of things that allow for some nice tricks (although I don't think they have been that well used). Wouldn't know about sound. I heard that the main CPU in the Genesis is more powerful than the one in the SNES, but I haven't verified that.
Comparing the SNES and the Genesis is harder than comparing the SMS and the NES, IMO.
Quote:
Play Castlevania II and you'll have the proof of that. (King's Knight is also a good example of this fact).
I know, it just happens. Be it because of time, budget or whatever, it is not impossible for good software houses to release crappy games.
Quote:
Wouldn't know about sound.
I think comparing SNES sound and Genesis sound (on a technical standpoint) would be hilarous. The difference between the SMS and the NES seems rather slight, as are the main differences between the Genesis and the SNES (graphically).
Built in rotation rocks, but you HAVE to use mode 7 to get built in rotation, and mode 7 has plenty of other stupid limitations (256 tiles available on total, all tiles use 8 bits per pixels wasting HALF of VRAM just for tiles, only one BG available, etc...).
However, when it comes to sound, in all objectivity, the SNES isn't comparable to the Genesis simply by the very large difference between both soundchips' nature. Personally I found Genesis games happed to sound a lot worse than NES, but that's just personal. I think well used square waves beats repetitive low quality digitalised instuments that are always the same.
Bregalad wrote:
Personally I found Genesis games happed to sound a lot worse than NES, but that's just personal.
It's FM Synth. FM is awful.
Worst fad in digital sound ever.
FM is a way to have complex instruments with constantly varying timbre without huge samples. I imagine it was attractive only because of the cost of memory and storage for samples at the time.
Quote:
It's FM Synth. FM is awful.
Worst fad in digital sound ever.
Well, think I'm not the only one to think that. For me FM was basically a technique from radios to converts modulated waves into usable sound, and I don't understand this. All I can tell is that Genesis music sounds awfull for my viewpoint.
It sounds alright when properly mixed with PCM and PSG. Bad examples would be early Megadrive games, or even Lagrange Point. Later Megadrive games sound better, eg. I was very impressed with Streets of Rage 2.
blargg wrote:
FM is a way to have complex instruments with constantly varying timbre without huge samples.
What good does complexity do be when it all sounds the same. I can spot FM a mile away -- that same stale sound of an old Casio keyboard.
*shudders*
But I know what you're saying. The actual waveforms generated with FM can get quite complex. And yeah I'm exaggerating about them sounding the same.
Quote:
I imagine it was attractive only because of the cost of memory and storage for samples at the time.
Yeah I'm sure you're right. I just look at the FDS's sound channel and imagine how they could have a 8+ channels of a more modernized version of that same concept --- it would just be
so much nicer.
Sure FM was a step up from straight fixed-form sound channels on the NES (basic pulse, triangle, etc), but I honestly think it was a step backwards from what things like the FDS were heading towards.
Thank heavens the SNES didn't take the FM route.
Disch wrote:
I can spot FM a mile away -- that same stale sound of an old Casio keyboard.
Yamaha keyboards are
FM synthesis. Casio keyboards are
phase distortion synthesis, which is subtly different to get around Yamaha's patent.
Quote:
Yeah I'm sure you're right. I just look at the FDS's sound channel and imagine how they could have a 8+ channels of a more modernized version of that same concept --- it would just be so much nicer.
That would be the Virtual Boy sound chip.
tepples wrote:
POW
I guess all my credibility of being able to spot FM a mile away was just shot to hell XD
Well played. hahahaha
Disch wrote:
Bregalad wrote:
Personally I found Genesis games happed to sound a lot worse than NES, but that's just personal.
It's FM Synth. FM is awful.
Worst fad in digital sound ever.
Oh you did NOT JUST GO THERE >=/
Seriously, though, the main reason people beat on FM synth so much is not because it's actually bad, but because most of the music on systems that use it uses it quite lazily. Especially when it tries too hard to reproduce real instruments rather than trying just to sound nice. If you look at some of the better Genesis games, some of the mid-90s commercial PC titles like
Descent, and
Lagrange Point, it can actually be quite good. (I admit that
Lagrange Point's is not quite as good, but that's more due to the severely limited nature of that particular chip than the nature of FM in general.)
I guess my main point is that the quality of the music has much, MUCH more to do with the time and effort put into it than it has to do with the nature of the sound hardware. Even higher-end wavetable chips like the SPC can still sound like crap in the hands of a lazy musician (I'm looking at YOU,
Super Ghosts 'N Goblins,) and even limited-technique hardware like FM chips can sound quite nice when some thought and effort is put into it (hooray for
Zero Wing, eh?)
P.S. The FDS sound channel also incorporated simple FM =P
Yuzo Koshiro put out a number of good/great sounding Genesis games but other than him and maybe Sonic Team, who else?
Yeah, unfortunately, many musicians (for a lot of US-made games...
) did horrible jobs of defining their instruments, so their FM music just sounds like croaking frogs.
Konami also did a piss-poor job when making FM music for Lagrange Point. I find the music just boring and lifeless. The simple OPL chip inside the VRC7 isn't at fault -- just listen to "Illusion City" on the MSX or some old Adlib (?) demo music to hear great FM music from similar instruments.
I guess I still like FM synth music a lot because a) a lot of great arcade games during the '80s had some fantastic and memorable FM music, and b) a lot of 70s rock & progressive musicians used similar FM syths. They've got a warm feeling to them.
Anyway, Yuzo Koshiro's been mentioned to death. Please go and check out Hitoshi Sakimoto's Megadrive compositions (like Gauntlet IV, Midnight Resistance, and Verytex) for another master of the more typical (ie, not dance-music) arcade-style FM music.
As far I know the FDS uses a waveform sampletable, like Game Boy's channel 3, and that's not FM I assume.
Quote:
And yeah I'm exaggerating about them sounding the same.
Not for the Genesis. For what Genesis I've heard, there were 4 instruments overall. A durm (and the same sound would simulate ALL drums), a kind of synth bass, an basic wave that sound like early digital organ, and one other wave which is used about everywhere and that sound like nothing (and sound very bad by the way). Also some noise is played I don't know if that's also a fifth instrument. At least it doesn't beat the NES' four fixed waveform in any way. The NES waveforms sound very clear and are very customizable. Genesis sound usually sound fuzzy, lound and agressive. I don't like it sounding at all. Lagrange point sound bad at some points, and I think it could be ported to pure NES music not so hardly and not sound much worse (just look at CV2 and CV3, I prefer their western version by far for music for some reason even if they use less channels), but Lagrange Point still sounds better than the very few Genesis games I've played under an emulator (those were Castlevania Bloodlines, Battletoads and maybe some other games I don't even remember).
Quote:
I guess my main point is that the quality of the music has much, MUCH more to do with the time and effort put into it than it has to do with the nature of the sound hardware.
Well, I partially agree. The sound hardware still have to offer nice sounds to the user. But that's true that you gan get great things with very lîmited hardware. Typically I think Gradius has awesome music for some reason even using only 2 of the NES' 5 audio channels !! For some reason Enix decided to do the same developpind Dragon Quest 1 (using only 2 channels) but most of it sounds bland to me (fortunately this will be fixed later in the series). I think a minimum of channels and features should be guaranted for good sounding music, but that bad use of any good soundchip will be bad, for sure. I'm sure there is Genesis games sounding good, I've just play none of them (I've only played about 4 Genesis games ever, and that under emulation so I'm not an expert here, heh).
Quote:
Thank heavens the SNES didn't take the FM route.
Yeah, I agree. Who knowns how bad would great soundtracks like Chrono Trigger or Tales of Phantasia sound on a piss SPU using some FM or AM technique.
Quote:
(I've only played about 4 Genesis games ever, and that under emulation so I'm not an expert here, heh)
Then what's with the strong opinion on it?:P
Please, try out Streets of Rage 2, Sonic the Hedgehog 2, and the games ccovell mentioned using a good emulator like Kega Fusion.
*edit* better yet, play the songs from
http://project2612.org/ in a player from
http://www.smspower.org/music/vgmtools.shtml
The only Genesis games that I can say sounded good were the Sonic games (particularily Sonic 3) and Zero Wing (beautiful music, beautifully rendered on the Genesis sound chip.) Lost Vikings and Comix Zone weren't bad either. But yeah, a lot of Genesis titles blew chunks; the most memorably bad in my experience is the 32X DOOM, because the original game had great songs which were fairly well-rendered on the default executable and fared even better when fans created a nicer OPL2 instrument set (found in zDOOM.) But the 32X version had the most muddled, muffled instruments and terrible drum sounds I've ever heard in a game.
But that ties back into my point, which is that it's not the hardware, but rather what you do with it. Certainly, the scores for Chrono Trigger and Final Fantasy 6 would have fared worse on the Genesis, simply because they use many real instruments or very close approximations thereof which are difficult to recreate even on detailed 4-op FM hardware like the Genesis has (strings are notoriously difficult.) But had Uematsu or Mitsuda or other similarily creative and intelligent composers been composing for the Genesis, they would have written and arranged music to fit what the sound hardware could do well, rather than taking grand aspirations of orchestral majesty and expecting them to work well on a synthesizer chip. This is why, when composing for NES projects, I always use Modplug Tracker with the NES waveforms and a few DMC drums and only five channels, rather than writing something grander and cutting it down to fit.
Yes, a large number of Genesis games use no more than a dozen instruments for the whole soundtrack, most of them cheap implementations of General MIDI standard instruments, but the sound hardware itself is capable of much, much more variety and much higher quality than that. The poor music quality is the fault of the game, not the chip.
Also, people had better quit beating on Lagrange Point or I'm going to have to get out the whacking stick.
Also also, technical detail dump time:
The FDS uses a waveform table, yes, but it also incorporates a lower-resolution frequency-modulation table, which is what I meant when I said it incorporates simple FM. Check out the falling-down-a-hole sound effect in Ai Senshi Nicol/Nicoru for a great example of this in use =)
The VRC7, while using a very similar synthesizer core to the OPL2 (Adlib,) is much more limited, in that it is stuck with 15 predefined instruments and one customizable instrument, so Adlib demo music isn't a very fair comparison. Illusion City is a much fairer comparison, since it uses essentially the same sound chip, the OPLL, although I believe the presets are different. And we can argue Illusion City Vs. Lagrange Point if you want, but that's much more a matter of personal preference than of technical aptitude.
The Genesis has two sound chips, the YM2612, which provides the FM sounds and is capable of a humongous (and I do mean humongous) variety of sounds, any of which may or may not float your boat, and the TI SN6489, which is the same chip as in the SMS and MSX (included for SMS backwards compatibility,) and produces three square wave channels (non-adjustable pulse width) and one white noise channel.
For the sake of completion, though I'm sure most of you know this, the SNES has one sound chip, the SPC-700, which has a CPU, 32KB of RAM, and a hardware waveform decompressor and 8-channel mixer, along with some simple noise-generation, envelop, and filtering hardware.
P.S. While I agree that a lot of many-channel music can be cut down to stock NES standards and still sound good, I'm going to have to disagree with you, Bregalad, in regards to CV3. Akumajou Densetsu's score is far, far nicer than CV3's.
Oh, I eventually give a try on those infamous Sonic games everyone are talking about. They really remeber me Donkey Kong County, but I guess DKC was a lot copied from Sonic in regard to release dates. They just have drums sounding a lot better than in CV-Bloodlines, but the main instruments are still similary fuzzy.
However, Street of Rage 2 really has great music ! It doesn't sound like the same soundchip at all ! I think if used well the chip can play very well synth-techno style music and is weak for melodic-classic like music, but still, SNES chip can do both. Genesis' SPU definitely CAN be well used, but it look harder to use than the SNES one. And all Genesis games I've tried had bland sound effects as compared to some SNES games or even older NES games. Well, some SNES and NES games have bland sound effects too, but most don't.
Also, it's good that sega decided to keep the old sound channels on it, because it's always cool to have several hardware square and noise wave channels hanging arround, like on the GBA for example. Filtered square waves of the SNES of Donkey Kong Country and Dragon Quest games doesn't sound too good I think.
Quote:
But had Uematsu or Mitsuda or other similarily creative and intelligent composers been composing for the Genesis, they would have written and arranged music to fit what the sound hardware could do well, rather than taking grand aspirations of orchestral majesty and expecting them to work well on a synthesizer chip.
I think you're probably right here, but a good melody will keep good played on any chip with any instrument I think. Only a few of CT's track, such as Magus Castle track or the drum-only track of pre-historic ages just cannot be ported on a older chip, regardless of how well the song is arranged. Otherwise, I think songs can very often be arranged to always sound decent on any soundchip.
Quote:
For the sake of completion, though I'm sure most of you know this, the SNES has one sound chip, the SPC-700, which has a CPU, 32KB of RAM, and a hardware waveform decompressor and 8-channel mixer, along with some simple noise-generation, envelop, and filtering hardware.
Actually the SPC-700 have 64kB of RAM, have complete looped samples support (as opposed to just waveforms) and have actually quite complex enveloppe and filtering hardware (filtering is ONLY applied to echoed sound, tough). Also you don't mention pitch modulation, wich is very useful for sound effects.
Mmm, it has 64KB address space, but as I understand it it only has 32KB RAM. I could be wrong though.
ccovell wrote:
Anyway, Yuzo Koshiro's been mentioned to death. Please go and check out Hitoshi Sakimoto's Megadrive compositions (like Gauntlet IV, Midnight Resistance, and Verytex) for another master of the more typical (ie, not dance-music) arcade-style FM music.
What can I say, Super Shinobi has always been my favorite Sega game :)
Nope, a lot of inacurate doccuments states so but it's wrong.
Also, I said something wrong - Street of Rage 2 music is bad. Just the first level one is barely good, and the thing get repetitive so fast !
I definitely don't like the Genesis sound chip at all, but it's just personal, and games can use it very well as they can use it very bad. I just don't like it's limitations. It does only play that crap old synth songs again and again, and I even prefer square wave and triangle wave music (exept for basses maybe, which are definitely the only decent thing the Genesis APU can output).
Also, I prever CV3 music on most songs because it just sound so much clear, clean, etc... Akumajo Densetsu music is better for a few song, such as the ending one. Some levels aren't much different, but definitely, for the first level, the music is SO much better in CV3 I found.
EDIT : Another dislikable thing on the Genesis is that of the few games I've tried all have diffent buttons config, while there is only 3 buttons. Almost all NES games have B=Attack and A=Jump, and almost SNES games have B=Jump, Y=Attack. Why should all Genesis games uses so much different buttons config ? I should rewire my joypad allocation each time I'm trying another game to have my traditional button setup. On the real hardware I assume it would be even more, taking the habbit of one setup for a game and then do everything wrong for every new game.
Generally on Genesis C is jump, B is attack, A is special. If games mix it up, it takes me only a few seconds to get the hang of it, there are afterall only 3 buttons.
the sega master system is way more powerfull then the nes itself.
it has a 3,58 mhz z80 proccesor.
it can display 32 colors at once out of 256 colorpallett.
only the japanese version has 10 fm audio channels /whereass the us,eu required a 6 channel fm module.
it has a rgb color pallett.
has no load issues compared with the nes zif loadsystem.
at the other hand the nes has 1 7bit pcm channel whereass the sms could only simmulate 1 bit pcm(by mixing those 4 psg soundchannels together and do some clever tricks to achieve this effect),also the nes soundchip is better then the us,eu sms soundchip,both systems has external soundpins input.
will the nes lacks rgb out, those composite video artifacts can give nice effects like water,rain,rainbow tranparancy,chain and can also give a ellussion of extra colors onscreen and it covers dithering artifacts.
the mmc5 chip dramatically extended the nes capability's too allowed more colers!!??,more & bigger sprites,more animations,more tiles,more effects,paralax scrolling and even rotations onscreen.
johannesmutlu wrote:
the sega master system is way more powerfull then the nes itself.
What? Necro-post aside, AFAIK things aren't how you've described (I'm not familiar with stuff either so my information is not supposed to be accurate):
Quote:
it has a 3,58 mhz z80 proccesor.
From what I've heard, because of different architectures you cannot compare the CPUs directly just with their clock speeds. It's said that in general the 6502 family can do stuff more efficiently in one cycle (or something like that), so at the end the CPU is not that much an advantage for the SMS.
Quote:
it can display 32 colors at once out of 256 colorpallett.
The Famicom/NES has a 54 colour master palette (without considering tricks such as colour emphasis and the like), whereas the master palette of SMS is 64,
not 256. (The Game Gear has a
4096 colour master palette though.) However, each graphic tile (background/sprites) can use only up to 4 colours(counting the transparent colour) for the Famicom and the SMS can use 16, so the SMS does have an advantage here(it doesn't have as much flexibility as the Famicom in having more subpalettes though; this problem still somewhat affects the Mega Drive).
Quote:
only the japanese version has 10 fm audio channels /whereass the us,eu required a 6 channel fm module.
???
The original Japanese Mark 3 and the export SMS's do not have a built-in FM unit, but the Mark 3 has an upgrade that adds this capability, which is never released for the export SMS's(they can be modded to have the capability though, and certain games DO benefit from this). The later Japanese SMS model does have the FM unit (and the 3-D glasses interface) built in.
Quote:
it has a rgb color pallett.
Yes. But whether this is an advantage or not is up to people's preference.
Quote:
has no load issues compared with the nes zif loadsystem.
I cannot comment on this, as the NES failed hard here. Only Famicoms were successful here.
Quote:
at the other hand the nes has 1 7bit pcm channel whereass the sms has only 1 4bit pcm,also the nes soundchip is better then the us,eu sms soundchip,both systems has external soundpins input.
I don't have much knowledge here but AFAIK yes one main advantage of the Famicom soundchip over the SMS's is the extra (D)PCM channel. The NES sort of failed though, that the external sound pins are not present on the cartridge connector(without modding that is).
Quote:
will the nes lacks rgb out those composite video artifacts can give nice effects like water,grain,rainbow amp,chain and can also give a ellussion of extra colors onscreen.
Again, whether blurry NTSC image is a good thing is up to people's own preference. HOWEVER, from
what I've heard (linked to Chris's page) while the Famicom has the pixel-shifting effect to minimise these artifacts the SMS (and, quite jarring, includes also the Mega Drive) actually does not have this, so instead the SMS output (when using composite) in general has
more such artifacts and blurriness.
Quote:
the mmc5 chip dramatically extended the nes capability's too allowed more colers,more & bigger sprites,more animations,more tiles,more effects,paralax scrolling and even rotations onscreen.
I think this is rarely used by games though.
Also, the list can go on, as there are different design choices in certain areas of the two systems there are things that can be done well in one but not the the other system. One example is:
The SMS design abused the background to the max, that background tiles can be flipped and each tile can choose from any of the two subpalettes, giving a maximum of 32... reee... 31 colours for the background plane. But the Famicom does not have hardware flipping for background tiles. On the other hand, the sprite capability of the SMS is quite limited. There is no hardware flipping capability for sprites (a horrible wall-banger) and so if say, your character can face either left or right in a game you either need to store two copies (but flipped) of the graphics in memory or has to flip the sprites in software (sprites can be flipped via the hardware for the Famicom) and only one 16(15 if you don't count the transparent colour) colour subpalette can be used for all the sprites at once (the Famicom has 4 different sprite subpalettes) and so if say you want a palette swap of the same character on screen at the same time (most commonly for 2-player co-op games) you have to store the graphics of both characters.
The result is, actually each of these systems has its own goods and bads, and it's quite hard to really compare which is actually more powerful. We do know who eventually wins the market in most places on earth though...
Like Gilbert pointed out, you got a lot of your info wrong.
As far as I know, the vastly different CPU architecture makes the processing power of both consoles roughly equivalent.
The ZIF connector used in the NES was indeed a very unfortunate design choice. Any console is better than the NES in this regard.
The difference in PCM precision is meaningless, since playing samples requires so much CPU time that it can't be used during gameplay, so it's just a novelty in both cases.
As for the illusion of extra colors, you don't need illusions when you can use 16 colors per tile. Still, these "effects" are also present on the SMS composite signal.
johannesmutlu wrote:
the mmc5 chip dramatically extended the nes capability's too allowed more colers,
The amount of colors is the same, what you get is better attribute precision for the background, which might make it look more colorful if used right.
Quote:
more & bigger sprites,
False. The number of sprites (64) and their size (8x8 or 8x16) remains the same, but you can have both pattern tables hold only sprite patterns.
Quote:
more animations,
Uh? That makes no sense. In fact, if you use the extra name table features, animating the background gets harder because you can't do it by bankswitching CHR as easily as in normal mode.
Quote:
more tiles,
True, you get to access more tiles.
Quote:
more effects,
Except for what you can do with the scanline counter (which is present in many other mappers), I can't really think of anything that a pure NES couldn't do.
Quote:
paralax scrolling
Sure, but you can do that with many other mappers, or even no mapper at all.
Quote:
and even rotations onscreen.
I'm not aware of any MMC5 rotation features, I don't think it has any.
tokumaru wrote:
The difference in PCM precision is meaningless, since playing samples requires so much CPU time that it can't be used during gameplay
I was going to chime in about the NES's capability of
rudimentary background PCM playback, but because it was a necro, I was hesitant.
Does the SMS VDP's data port allow loading tile or map data during active picture time (that is, not during vertical blanking)? The NES PPU's doesn't, but the Genesis VDP has a four-write-deep FIFO for this.
I've never found the SMS to be superior to the NES. In practical terms I don't think the CPU performs better. The graphics display allows for more color depth with is certainly an advantage. But it seems to me that many NES games still managed to look as good or atleast not far behind in that department. Also many NES games thanks to CHR-ROM have lots of animation very smoothly that I did not really see in any SMS games I've played though I haven't played a ton.
Really it's a silly debate though as superior hardware means nothing, software is everything. You can have amazing hardware and it means nothing if you have no software people want to play.
johannesmutlu is trolling. Why else would he bringing up posts like this?
Gilbert wrote:
Quote:
it has a 3,58 mhz z80 proccesor.
From what I've heard, because of different architectures you cannot compare the CPUs directly just with their clock speeds. It's said that in general the 6502 family can do stuff more efficiently in one cycle (or something like that), so at the end the CPU is not that much an advantage for the SMS.
That's exactly right. To put things into perspective, most opcodes on the NES are between 2-5 cycles, because it does multiple things per cycle. On the Z80,
everything uses a multiple of 4 cycles per command. As for the actual instruction set, both processors have their strengths and weaknesses. For example, being able to easily do 16-bit operations on the Z80 is pretty useful. However, the zeropage and the special (faster) ZP addressing mode on the 6502 is quite handy too.
Though, it'd be nice to be able to flip the BG tiles, like you can on the SMS, but then again, I think the SMS can't flip sprites. On the other hand, neither could the MSX, and that's still a pretty highly regarded system itself.
I dunno, I don't think it's the capabilities of the system that makes it better, it has more to do with how you work within the restrictions.
tomaitheous wrote:
johannesmutlu is trolling. Why else would he bringing up posts like this?
-
YES, and he's not the first. Probably the same guy a few days ago.
tokumaru wrote:
The difference in PCM precision is meaningless, since playing samples requires so much CPU time that it can't be used during gameplay, so it's just a novelty in both cases.
Some games did it anyways, like Ultimate Stuntman (unlicensed) by Codemasters. In-game it doesn't sound that great though because they only write the samples during ~100 scanlines, but it's decent.
tepples wrote:
I was going to chime in about the NES's capability of
rudimentary background PCM playbackYeah, the NES at least allows *some* kind of background PCM playback, even if it's not at full quality. Objectively speaking, I believe the NES wins in the sound department. Subjectively speaking, I think the SMS has better graphical capabilities, with the only real disadvantages being that you can't flip sprites or bankswitch tiles, and that the number of available tiles is smaller because their VRAM is also used for screen maps ("name tables") and sprite data ("OAM").
Quote:
Does the SMS VDP's data port allow loading tile or map data during active picture time (that is, not during vertical blanking)?
I believe it does, reading and writing, but there's some kind of speed penalty.
MottZilla wrote:
Also many NES games thanks to CHR-ROM have lots of animation very smoothly that I did not really see in any SMS games I've played though I haven't played a ton.
I think it's possible to update a decent number of tiles per frame on the SMS, but unfortunately a lot of that time is wasted on updating the player's tiles, partly because of the lack of sprite flipping. Still, I'm sure some games had good graphics and some level of background animation. I'll let you know if I find any good examples.
Quote:
Really it's a silly debate though as superior hardware means nothing, software is everything. You can have amazing hardware and it means nothing if you have no software people want to play.
For common retro gamers yes, but a lot of us are developers, so we are able to look at these consoles and see their potential regardless of what has already been released for them. Nintendo's business tactics were pretty dirty back then, and they did everything to keep developers from releasing SMS software. If that wasn't the case, I believe we'd have seen many more impressive SMS games.
EDIT: Another advantage I can think of about the Master System: I'm pretty sure it has a built-in scanline counter, which means that raster effects are much easier to perform. It's not perfect though, I think it doesn't generate interrupts, so the only way to use it is polling a register, much like the NES with sprite 0 hits, but still much more versatile than those.
tokumaru wrote:
tepples wrote:
I was going to chime in about the NES's capability of
rudimentary background PCM playbackEDIT: Another advantage I can think of about the Master System: I'm pretty sure it has a built-in scanline counter, which means that raster effects are much easier to perform. It's not perfect though, I think it doesn't generate interrupts, so the only way to use it is polling a register, much like the NES with sprite 0 hits, but still much more versatile than those.
Yes, it has a
scanline counter, but it also has
interrupts (see section 10). It is very handy, considering the fact that many SMS games (especially earlier ones) use it to generate parallax effects of the playfield. One problem with the SMS is though, I think you cannot modify the Y scrolling value within a frame (I'm not so sure about it) and because of this you cannot do things such as a static status bar on the bottom of the screen and the upper part scrolling vertically (you have to jump through hoops to do this on the NES but at least this can be done). There is a hardware function to lock the first two rows of tiles in position to make for a status bar though. However, it is a bit limited as two rows isn't much (not to mention that these two lines are off-screen in GG mode and thus useless for GG games) and many SMS games actually don't have information such as scores and remaining life displaced onscreen (the default screen height of 192 lines may also be a factor).
SMS:
- You cant change the Y value during active display. Only the X value
- Tilemap size is only 256x224. The display is 256x192 (a few odd tricks/registers can get it to display a little more vertical res)
- There's a bit in Reg #0 to blank the leftmost 8pixel column (to reduce map update artifacts)
- Tile map entry include a priority setting per tile. Very useful IMO. You can do more complex over and under lapping part of the BG to sprites
- Sprites have no priority settings related to the BG
- Tilemap can assign one of two 16 color subpalettes to a tile
- Sprites are fixed at using one 16 color subpalette
- sprites can only access 256 8x8 cells or 128 8x16 cells
- There's a register to add an offset for accessing upper 128 8x16 cells (for the whole SAT)
- Only a first few sprites can be 'scaled'. I don't remember which doc, but Charles told me himself that is was probably a bug from the older TMS video chip logic
- tiles can access 512 8x8 cells
- If 8 pixe left shift bit enabled for sprites, sprites won't wrap horizontally around the screen.
- the top 16 pixels of the display can be left static and untouched by X position for a fixed bar display
- the left most 64 pixels of the display can be left static by the Y position of the display for a status bar on vertical scrolling screens.
- The SAT (sprite attribute table) is convoluted in its layout for X and Pattern bits
- VRAM isn't fast enough to complete blit/transfer too. Care has to be taken for fast OUT commands (IIRC) on the real system.
- Sprite to sprite pixel collision (non transparent), but it doesn't tell you with ones.
- No autoincrement other than 1
Also, I hate how they extended the 'command word' function into the Genesis VDP. Stupidest method of selecting a VDP command ever. Ugh.
tomaitheous wrote:
SMS:
- There's a bit in Reg #0 to blank the leftmost 8pixel column (to reduce map update artifacts)
There's a bit in Reg #1 of the NES PPU to do the same thing, yet because of the 16x16 pixel subpalette areas, map update artifacts still show up in H-mirrored and 1-screen games.
Quote:
- Tile map entry include a priority setting per tile. Very useful IMO. You can do more complex over and under lapping part of the BG to sprites
- Sprites have no priority settings related to the BG
Bass-ackwards: it's like a fish, but in reverse.
- On NES, only sprites can be flipped; on SMS, only background tiles can.
- On NES, only sprites have priority; on SMS, only background tiles do.
- On NES, only sprites can access all of VRAM (in 8x16 mode, with caveats related to scanline counters on some mappers); on SMS, only background tiles can.
Quote:
- VRAM isn't fast enough to complete blit/transfer too.
What exactly do you mean by this?
I wasn't particularly listing plus, just capabilities in general. But I do think that each 8x8 tile having it's own priority is a pretty good idea. Really wish the TG16 had that ability.
Quote:
- VRAM isn't fast enough to complete blit/transfer too.
What exactly do you mean by this?[/quote]
Came up in some demo designs. I don't know the specifics, but it has to do with the fastest way to send bytes to vram port on the SMS. I'll ask Charles Macdonald this week end for more details.
tomaitheous wrote:
SMS:
- You cant change the Y value during active display. Only the X value
How does
this work then?
Do you mean the status bar at the bottom? There are no more than eight tiles in each scanline, and the background is solid. Also notice the blank lines between the playfield and the status bar. I'm guessing sprites, with the display list getting rewritten during the blank lines.
Indeed, looking at the background tile map in an emulator I can see it has just the solid color, the contents are sprites.
How exactly do
this status bar work?
RT-55J wrote:
tomaitheous wrote:
SMS:
- You cant change the Y value during active display. Only the X value
How does
this work then?
The name table (tilemap) is defined by the address pointer register. You can update the pointer to any other point in vram *per* scanline (or interrupt).
The SAT (sprite attribute table) also can be changed on a scanline basis, but the SAT is parsed on that scanline for the next, so the update takes effect on the next scanline.
Also, about the sprite scaling. If you have the bit enabled for double scaling of sprites (X and Y), and you have 8 sprites on a scanline; the first 4 will scale/double correctly but the second 4 will only double vertically - not horizontally.
SMS2 and GG fixes this issue.
CRAM can be updated per scanline, but the z80 is too slow to update all 16 colors and you'll get snow onscreen. It's possible to update a few colors without snow though.
Updating vram during active display is possible, but you have to carefully delay your writes else they'll get corrupt.
There was something about a chained series of OUT writes even during vblank, but I don't particularly know the details. Normally not an issue.
Quote:
How exactly do this status bar work?
Same as I described above.
RT-55J wrote:
How exactly do
this status bar work?
Look at the tilemap viewer and notice how each bar is 16 pixels tall. That's enough to render 8 scanlines of them no matter what the fine Y scroll is (apparently you modify the Y scroll at the tile level, but not at the pixel level). The text is made of sprites.
Wow, this sure is a very clever trick ! Congratulation to those who programmed this game.