Color counts per screen

[Eke]

I agree about the timer IRQs though - that's something I never understood.

I think this is (again) tied to the VDP design choice.

It was supposed to handle interrupt lines directly (and handle acknowledge from bus arbiter). I bet the logic would have been more complex to add YM2612 IRQ in that scheme: simply connecting it to /IPL0 would not have been enough to use it properly, you would have need additional logic (which has its costs) to differentiate between INT2-4-6 (from VDP), INT1 (from YM2612) and INT 3-5-7 (VDP+YM2612 simulatenously),

I agree with tomaitheous, I think that many restrictions are due to the choice they made to keep backward compatibility, it was also probably cheaper & easier to "upgrade" the SMS VDP rather than designing a new one: regarding color limitation, as said above, you only have room for 2 palette bits (i.e 4 selectable palettes per tile), they could have multiplied this by 2 or 4 if they removed hflip/vflip features or increased the description field size but then it comes to VRAM size limitation, same goes for the choice of using 4-bits per pixel (16 selectable colors per palette), more would have mean bigger VRAM, wider VDP internal address bus, etc... it's all about compromise and design choices, off course the more features the better but it's very hard to have an objective view on the subject without having yourself ever designed a commercial (and viable) console system

[sheath]

First off, what does composite have to do with anything? Are you making some sort of handicap for the Genesis via its unique (crappy) composite video? I hope not. I've seen this quite a bit of this amongst Genesis only fans (and pretty absent from EU Megadrive fans as they ran RGB) and trying to make the exception by saying one needs to run via composite out to really compare the pics. The only thing the care about is making the Genesis out in a better light, and not an objective comparison. That's biased crap. Funny, I remember recently having this conversation with a Sega-16 user. He only wanted to do comparisons of Genesis games to SNES games in composite form - nothing else. The reasons were obvious, the composite hid a lot of real output limitations of the Genesis. He tried to say that it also helped the SNES, and that was justification. But it didn't really help the SNES at all. Looking at the SNES in RGB vs Composite, it either looks the same or better. The composite output of the Genesis only helped in the Genesis because of its really low color/detail count. If you ran a SNES through the same 'Genesis' version composite output, it looks awful. Totally kills the detail and colors of the SNES shots. Funny how, when he posted some emulation screen shots with the NTSC filters on and saying that's what he's going to use because that's what he grew up looking at, that EU gamers chimed and said they never grew up with their games looking like that. It's one thing to make a 'note' about how BITD the crappy composite output of the Genesis (which they refused to fix through out all of their 8-9 board revisions, some even major ones) and totally another thing to make an exception or even rule to only show them in every comparison shot. That isn't being objective by any stretch of the imagination. Unless focus is about composite vs RGB and not game graphic comparisons between systems.

I'd say that it amazes me that you could write such an incredibly long paragraph like this and think it's not biased, but I'm really not amazed. It isn't your fault either, bias is inevitable. I like the Genesis because I like the games I can play on it. I also own a DUO/R and SNES that I keep hooked up to the same television at all times. I find them all to have strengths and weaknesses that affect certain game types in most cases. Because I have found this, I am by definition biased. You cannot escape this either, especially with the unreasonable statements you have so flagrantly made above.

Noting the color and subpalette capabilities of both systems, and you looked at a PCE game and saw that it had a specific type of color choice, palette, or missing color detail - then it would be obvious that it was an artistic choice (assuming all other things available). You can't say the same about a game on the Genesis. In those shots, it's obvious that form derives from limitation. Dimmer colors blend easier.

I actually can. In the comparisons I am working on right now, including Lunar 1+2, Vay, Puggsy and Fink for Sega CD, I can see numerous artistic choices that included very obvious dithering that I cannot see the artist choosing if he/she were aiming for an HDTV or PC monitor. I say this because other scenes very obviously use other artistic approaches to make color selections as low as 16 look like a portrait. So, if we were comparing apples to apples instead of apples to watermelons, the obvious limitations of Megadrive games' palettes would *not* be so obvious.

Exaggerate? Using 32x16color notation is exaggerating? Saying that it has 32 subpalettes is exaggerating? Explain.

Are you being serious? A single background limited to 8x8 tiles is limited to 16 palettes, and the sprites are limited to another 16 palettes. I presume that the total palette is indeed made up of 512 unique colors, but with this limitation between the background layer and sprite layer (not even including my theory about ROM size) I can see why no PCE/TG16 game, in your experience, exceeds 128 colors simultaneously. In my experience no PCE/TG16 game exceeds the mid 90s, but I have not played and taken screenshots of them all.

.... then why did you??? You added vram to work ram on both systems, then divided the total between the systems. If you knew they couldn't be mixed, then why did you? I'm confused.

Because RAM costs money, and you are asserting that the relative lack of RAM (or an extra chip?) for color palettes on the MD/Genesis is "inexcusable". With how detail oriented you are, I am really surprised that you would ask me this question again.

(snip)
Backwards compatibility was once of the most worthless features of the Genesis. It's a 16bit console from a 16bit generation. The fact that you were one of the very few that had an SMS, doesn't make it the exception to prove the rule, it just makes you the exception to the rule.

I only know that every Genesis owner that I have talked to considers it so, and every game magazine article, in the UK and US, makes sure to mention it. What do you consider of the PS2, PS3 Wii and Xbox 360's backward compatibility?

Looking at SMS BC in context. (...) Hell- we were a multi console family, never had an SMS or cared about it, already had an NES and TG16 and home computers, and we still jumped onto the Genesis very-very early on.

Sega was never the top dog, even though the Genesis managed to make it seem so in the US for a few years. The issues you are bringing up are so multi-faceted that they cannot be addressed in this topic. How much money did Sega have to work with versus Nintendo and NEC? How much money did Nintendo and NEC dedicate to game consoles instead of other industries. How much did Sega spend developing arcade machines (their main breadwinner as you said). These questions have to be answered in extreme detail before your your assertion of anything being "inexcusable" can have any meaning.

(snip) If you removed the cost of the z80, the z80 ram, and the SMS video modes - I'm sure you'd recover cost at a minimum for the addition palette memory on the VDP IC. (snip)

So you would say that the additional RAM for more palettes was worth more to consumers at any point during the MD/Genesis life cycle than SMS compatibility was. How would you prove this?

Now, If you're thinking the z80 is required to audio and such. Wrong. For one, FM audio is extremely light on system resource. Offsetting FM updates to the z80 might save you something like less than 1% cpu resource. What about DAC updates? The YM2612 has two timers and trigger lines for interrupt (...) But even without it, cpu at 7.67mhz easily had the resource to handle the relatively small overhead.

Why does the PCE-TG16 not use FM sound then? Why do the MD/Genesis or TG16, moreover, not use the SNES approach of an all ADPCM system? I think it's because technology advances, becomes cheaper, and otherwise changes every six months. As for the Z80, nearly all of the arcade systems from the 80s used it, and nearly all of the 68000 based systems had it as a coprocessor of some sort. There must be a reason why.

(snip) You are right, portability of code is one factor. It's easy to speculate *one* of the reasons why Sega went with the 68k is because porting code from 68k arcade systems would be facilitated by using the same processor (that doesn't mean you can run direct 1:1 code on the some, (snip)

Of course, these things are obvious. I would also assume that Sega had a good arrangement for 68000 manufacturing since they had been using them in Arcades. Portability was just one of the reasons I listed.

My main point was that both systems aimed to be relatively compatable/capable of working with the previous generation of hardware/software *and* arcade games. That is opposed to the idea that I keep hearing you and others say, that Sega (in particular) should have designed a system that would look acceptable (without filters) in emulation twenty years down the road. Despite your and my bias on the subject, I sincerely doubt that displaying these games on a computer monitor ever crossed these company's collective minds.

You have 65C02, but stock they weren't running past 4mhz at the time. 65816 wasn't available IIRC. (snip) Some of the factors for choosing a custom 65c02 for Hudson portability of code (obviously getting companies/programmers already familiar with the famicom processor to be setup in a familiar environment), but also (snip) But the video and sound of the PCE? Couldn't *be* more different than the FC in design and interface. The only thing they have in common, is that they are tile/sprite based systems. Just like the Genesis is.

Okay, I saw that you had compared the way the TG16, NES and SNES CPUs operated and contrasted that with the 68000's approach. The CPU similarities was all I was referring to, I am well aware that different video systems need to be coded to specifically.

We can bet that the Genesis has a more expensive CPU, VPU, and Sound system, because it has more chips. In the process of cost cutting, and knowing full well that RAM was *very* expensive in the 80s, we can look at the CRAM choice in the Megadrive in context.

In which context? From 1987-88 or mid 1990s? Looking at it context of itself, relative to cost, still doesn't change it relative to other consoles. And like I said previously on the matter of BC, it's even more of a poor choice if you're strictly looking at cost.

Sega!=Sony/Microsoft, they could not ever afford massive losses per console sold, so cost factors were important in 1987-88 (when nobody knew whether the hardware would flop in two years). Your comments on backward compatibility are only your subjective opinion, not fact. In the case of the PS2 they actually included PS1 hardware in the system, in the case of the PS3 they actually cut PS2 hardware out to save costs when the system didn't sell well. Backward compatibility became the standard in the industry, regardless of your opinion of its importance.

Wait, what? The z80 and VDP are two different things. They are not even remotely related. The PCE has a simple solution; any additional ram needed can added to the cart. RAM prices had an overall trend of going down since RAM became available in IC form in the '70s. It's a reasonable expectation that the price of ram is going to go down. And since it can easily be added to the cart (it doesn't appear any different to the system or the programmer), it's a perfectly reason way to cut cost. Hell - Nintendo did just this on the Famicom. ALL tile/sprite VRAM was on the cart, not the system. That lowers the price of the system during it's original release period. You can't simply do that with the palette ram issue on the Megadrive. They never made the palette ram external, nor did they make it accessible via an upgrade through the cart port. You yourself need to take a step back and look at the analogy you're trying to make. You're comparing the act of cutting system ram to that of internal palette ram. One is easily rectifiable via cart or backplane, the other is fixed in stone. I would say the two aren't comparable decisions. If anything, it makes the choice on Sega's part even more inexcusable.

What? I thought the Z80 and the VDP were on the same chip!??? Just kidding. I was throwing out random examples, anticipating you wanting to carve the system up arbitrarily so it could still be "inexcusable" to not add more CRAM. RAM on the carts raises the average cart cost and severely limited the sell through of games. I've also seen several executive interviews where they said they had *no idea* if costs would come down *in time* for them. These machines were huge gambles no matter how you look at it.

But I can see that you're not going to come around on this topic and neither am I. This is what you need to prove your point, an interview with somebody within Sega that specifically discusses the color issue that proves Sega considered the options you consider "simple" and tossed it out for an invalid reason. Then and only then does the decision become inexcusable.

This isn't even considering the likelihood that PCE engineering process occurred under an entirely different economy than the Megadrive process did (1986-87 versus 1987-8 )

That a bit of a stretch, don't you think???

So I take it you think from year to year all hardware costs came down, and none went up? That's a big assumption.

That's nothing more than a HSL map of the RGB values. It's not the whole palette map of either system. Different maps are used as aids for a graphic artist. I have made a few different maps myself. And most of them don't show all 512 colors. Look the second image you posted. It's not easily picking colors from that 512 color map because.... (tada) the perception of color is relative to adjacent colors. Color 101.

(snip redundant SMS conversation)

I say all of that to point out that your opinion on SMS compatibility is just that.

So is yours. At least his (and my) opinions were that of the vast majority. I.e. more representative. Popular opinion is still popular opinion, is it not? You yourself have used it in this thread when it suits you/aligned with yours.

Right, our opinions weigh the same on this matter, and you don't know the "vast majority" opinion. The only facts are that Sega included SMS compatibility, and NEC did not, which opens up the whole cost discussion. Our individual experiences are only anecdotal evidence, which people can accept or toss out as irrelevant and be just as correct.

And what do you think your conclusions will mean? It still does nothing to alleviate the fact that the one system games are is bound by color/subpalette restriction and the other is systems games are bound by artist choice. For the record, Lunar are very bland and/or dithery games. I never understood why people used them as graphic examples on the SegaCD. If anything, they show off the limitations more so.

Actually, my opinion is that the actual console output almost entirely alleviates the color issue from a gaming (i.e. not developer) perspective. The cost discussion lends context to the relative lack of colors on the Megadrive, which you did not provide before pronouncing it "inexcusable". The way you paint it one would assume Sega had a bunch of monkeys engineering the system and the decision to include more colors was just right their with no other considerations against it. When I pointed out those considerations, you dismissed them, and yet their existence contradicts your assertion.

Ah, that was my point again. Are you playing Genesis titles via emulators or on a standard def television?

Again, read my above response to such nonsense. If you're going to insist on comparing in composite as a real measure, (snip)Sigh....

Your bias lies here, mine lies with the actual system outputs. When I do a comparison, I use the highest common denominator to compare graphics apples to apples. The only thing I will use emulation shots for is to demonstrate the actual chip output, it is not representative to what the artist was considering "normal" nor what "the vast majority" of gamers experienced in the 80s or early 90s.

There's an option in Kega to capture unfiltered "raw" shots. If you can't find it, you can always turn off all scanline, NTSC correction, and other filters to get a raw shot (minus nearest neighbor scaling horizontally, but that doesn't effect colors).

I already did that, some shots still came out wrong, it is probably because I had them taken at double resolution. When a 16 color picture in Lunar shows up as 110 something is very wrong . At any rate Gens is working fine.

I noticed several times during this process the importance of the shadow and lighting effect. Even Xanadu 1&2 use something similar when popping up messages and trying to darken the background. Mortal Kombat uses for fatalities. Smart developers could actually use it for object shadows rather than using a whole new palette. The applications are numerous, but the actual usage is limited. to certain types of screens and rarely used in action scenes.

My response to the part in bold, yes you can. But how does having a transparent (brightness only) shadow increase detail via color? In fact, it doesn't. You get a high color count without direct correlation to detail for the higher color count.

No it doesn't increase the actual colors, but it does have a function, which is what I was pointing out. We both agree that cutting S&L out would not have freed up enough cost to add RAM, I was just pointing out that it is better to have it *in the Megadrive* than to not have it.

(snip)Do you not understand what S/H is doing on the Genesis? PCE has no such hardware, so how could it be doing the same!? Just because you happen to see light/dim transitions, doesn't mean that's "shadow/highlight". That dim part of the display box on the PCE, is not limited to brightness. It could hue based as well. The only reason it's brightness based is to you can read the text easier, without having some solid color behind the text. It's nothing more than changing the tiles on that part of the map to use a different subpalette and such. Xanadu hardly pushes the PCE graphics or color wise. Just playing the game is evident. It's fun and I like the art style, but it's hardly impressive. Xanadu 2 has nice pixel art, but some of the color choices are too drab for me tastes in some areas for the overworld. The boss battles look beautiful though.

You completely misunderstood me. I know the PCE doesn't have the effect and so must swap palettes. I was pointing out that certain screens darken and lighten to *to the same effect* in PCE games. Thus the effect had a use in the games.

(snip pics and FF comparison)

My Strider hand conversions yielded better results like this too. Which brings up another point. The ACD version of Strider is sooo shitty looking. It also isn't a limitation of function. Though that game is a combination of a series of mistakes. Some of the stuff is from an old project, some of the stuff is newer (like the sprites). Except, the totally fucked up the palette associated to pixels in that game. A lot of the sprites are just the arcade version rescaled to fit low res. They still have the all of the arcade pixels there. But whoever did the palette conversion just made duplicates palette entries. In other words, there's hidden details in many of the sprites. This wasn't a side effect of memory to anything but sheer stupidity. I went in and did a palette hack to recover the missing pixels/detail. They looked great. Of course the rest of the game is still a pile of crap (AI, gameplay mechanics, sprite management, BG tiles ,etc).

This and other examples actually begs a question you are not addressing. With all of the extra palettes "available", why did developers choose to not use them? Your Final Fight and Street Fighter examples expose something that disagrees with your assertion that colors matter as much as you are trying to make them. ACD Strider doesn't look as colorful or animate as well as the 8Mb Genesis Strider cart, Riot Zone SCD doesn't look as colorful or as animated as its arcade counterpart or Final Fight CD. Did the developers just not have the competence to make a game for the PCE, Capcom and Westone, really?

I can look at *any* game and wish the artist hadn't done something, I'd just as well never see dithering in a game, ever, but I see it even in PS2 games. I hate dithering, I can always tell when its there especially when it's used in backdrops, and yet graphic artists use it all the time to save something somewhere. In the case of Probe titles for the Genesis, I think they were just sloppily porting SNES games and didn't want to redraw anything, but I can't prove that.

Moreover, Probe achieved its target results, they sold tons of MK 1+2 titles and got them out in time. What's worse, in emulation I can see even more dithering than I could on my television set, even Lunar 1+2 are marred by it when they looked very tastefully drawn on television. Why did they use dithering instead of just drawing clean lines and using other approaches if it wasn't because they were aiming for composite out? The answer should be obvious, the developers weren't looking at the same output as you are.

[tomaitheous]

I'd say that it amazes me that you could write such an incredibly long paragraph like this and think it's not biased, but I'm really not amazed. It isn't your fault either, bias is inevitable. I like the Genesis because I like the games I can play on it. I also own a DUO/R and SNES that I keep hooked up to the same television at all times. I find them all to have strengths and weaknesses that affect certain game types in most cases. Because I have found this, I am by definition biased. You cannot escape this either, especially with the unreasonable statements you have so fragrantly made above.

Don't confused having an opinion with being biased. You're using composite to defend a system against criticism of its graphics. You're using is as a crutch to say, "Hey, it wasn't meant to be viewed on an emulator 20 years later". Bullshit. Genesis/Megadrive came with RGB as an option from day one. Not only was it a valid option, it was used by quite a bit japanese and european users. If the system ONLY had composite output, then you'd have a basis for an argument. I hold PCE to the same standards, even though there were not official RGB cables and it also required an AMP to have a usable output. I don't make any handicap for the PCE. Nor do I for the SNES. So really, who's being bias in their comparison.. hmm?

I actually can. In the comparisons I am working on right now, including Lunar 1+2, Vay, Puggsy and Fink for Sega CD, I can see numerous artistic choices that included very obvious dithering that I cannot see the artist choosing if he/she were aiming for an HDTV or PC monitor. I say this because other scenes very obviously use other artistic approaches to make color selections as low as 16 look like a portrait. So, if we were comparing apples to apples instead of apples to watermelons, the obvious limitations of Megadrive games' palettes would *not* be so obvious.

Really? You've never seen dithering to expand gradient on any other system that had RGB/monitor output put!? I find that hard to believe. Also, the dithering is there BECAUSE of the limitations of the subpalettes. Whether you think it's ONLY for composite output or not, is irrelevant. It serves the same purpose be it RGB monitor or composite or whatever. You really need to look at some Japanese PC games.

Dither serves two purposes. One is to add texture to an image. This is pretty apparent when it's used in this way. It DOESN'T lower the horizontal res when used in this method. The other use is to created the illusion of more detail in color. And it DOES reduce horizontal resolution (because you need two pixels to appropriate a single color). Genesis don't hold the monopoly on the second case, but it has have much more frequent use because of the DIRECT limitation of only having four subpalettes on a 4bit graphics system. PCE games also have examples of the second method.

I'm beginning to think you don't know what you're looking at or looking for.

Are you being serious? A single background limited to 8x8 tiles is limited to 16 palettes, and the sprites are limited to another 16 palettes. I presume that the total palette is indeed made up of 512 unique colors, but with this limitation between the background layer and sprite layer (not even including my theory about ROM size) I can see why no PCE/TG16 game, in your experience, exceeds 128 colors simultaneously. In my experience no PCE/TG16 game exceeds the mid 90s, but I have not played and taken screenshots of them all.

So what if it's not all for the BG layer? Are you daft? Do you not see sprites moving around on the system. Did you NOT understand about I and some others have mentioned about EXTENDING the Genesis VDP for the sprites to use their OWN 4 subpalettes? No different from that. Just because the sprites have their own separate 16 subpalettes that, somehow makes them less applicable? Jesus man, you need to get some experience with graphics so you'll understand this concept -_-;

Because RAM costs money, and you are asserting that the relative lack of RAM (or an extra chip?) for color palettes on the MD/Genesis is "inexcusable". With how detail oriented you are, I am really surprised that you would ask me this question again.

Let see.. just to put this back into context..
RAM:

The PCE has 8KB of RAM and 64KB of VRAM, for a total of 72KB (totalled only for cost purposes). The Megadrive has 64KB of RAM and 64KB of VRAM for a total of 128KB of RAM. Since I have no knowledge otherwise, I will assume that each byte of RAM cost the same between the two systems, and between the system's RAM and VRAM. The Megadrive has 1.777 times the RAM that the PCE has.

You: doing exactly what you said you understood was not accurate. Me: calling you out on it. You: merging what I said with something else that I said to try to prove... some sort of point (looks like you trying to cover your butt or something). I don't see how system ram has anything to do with onboard IC palette ram. Let alone what this has to do with your original incorrect logic.

I only know that every Genesis owner that I have talked to considers it so, and every game magazine article, in the UK and US, makes sure to mention it. What do you consider of the PS2, PS3 Wii and Xbox 360's backward compatibility?

Go over to Sega-16 and take a poll that asks if any Sega fan or just Genesis gamer in general, would have bought the Genesis/Megadrive if it DIDN'T have BC BITD. I think you'll get a huge majority response saying that SMS compatibility was a non factor. It goes without saying, people aren't interested in playing the last gen games when something new and exciting is there and accessible. 360 doesn't have BC, it has recompiled cores and no, it didn't make a lick of difference. Same on the PS2 with PS2. How many people do you think bought a PS2 thinking, "Wow, I can play crappy looking PS1 games! Woohoo!". Wii is the exception to the rule.. for the very fact that the system isn't a new console. It's a slightly upgraded Gamecube with a new controller interface. So not really relevant. PS3, same as the other systems. The difference from SMS to Genesis was fricking HUGE. I don't know of anyone that wanted to play SMS games when at the time Genesis games were soooo exciting in every category. I don't care what the magazines reported or listed. No one cared. Heh - you might have half a point if the Genesis was NES BC (because 8bit Megaman was still popular in the 16bit era)

So you would say that the additional RAM for more palettes was worth more to consumers at any point during the MD/Genesis life cycle than SMS compatibility was. How would you prove this?

Easy. 1) See above response. 2) A lot of Genesis fans were insecure about the systems "color" capability early on (relative to it's life span). The Super Famicom, even before it made its appearance, being shown in magazines and such - was clearly showing the lack of "colors" on the Genesis. Coupled with magazines (namely EGM) constantly mentioning the limited "colors on screen" amount of the system. It was there. All my friends talked about it. And it became very when the SNES was released in '91 (which is 4 years before the death of the system). Ignoring all the detail and color range increase it would have provided upon initial release (giving the quality of softs and what they were already showing). Should I mention the PCE was already out a year before the Genesis? I can't believe this even needs to be discussed (again!). Ugh.

Why does the PCE-TG16 not use FM sound then? Why do the MD/Genesis or TG16, moreover, not use the SNES approach of an all ADPCM system? I think it's because technology advances, becomes cheaper, and otherwise changes every six months. As for the Z80, nearly all of the arcade systems from the 80s used it, and nearly all of the 68000 based systems had it as a coprocessor of some sort. There must be a reason why.

Yeah, backwords compatibility. You think the Amiga needs a z80 to do music? Hahaha - do you really think the PCE has no FM because it lacks a z80??? If NEC has built the PCE, it would have had an FM chip without a doubt (ALL their computers used FM chips). So you'd have to ask Hudson why they didn't go with one. The CD unit, released in '88 the same year as the Megadrive - didn't use a FM chip because CD audio was perceived as a bigger upgrade in audio/music (as an option). Arcade systems are NOT home consoles. Their video setups are incredible in comparison and they spent money on hardware with a totally different mind set. Trying to link the two is ridiculous. That X68000 machine completely blows away the Genesis in every category and yet... totally lacks a z80! The z80 was there in the Megadrive for backwards compatibility. Because they gave the option for the 68k to memory map in sections, doesn't allude to this fact.

ADPCM has almost nothing to do with the SNES synth system. It's just the format of the wave form. Nothing else. And the PCE is pretty similar to the SNES. It uses PCM waveforms just like the SNES. It's just that the PCE is limited in size of the waveform in comparison to the SNES (of things being relevant to the audio system). SNES is sample based synth, PCE is Tiny sample based synth. Or as a few pce coders nicknamed it WSG (as some japanese docs/mags have reference it as). But, audio isn't part of this topic, so I'll leave it at that.

My main point was that both systems aimed to be relatively compatable/capable of working with the previous generation of hardware/software *and* arcade games. That is opposed to the idea that I keep hearing you and others say, that Sega (in particular) should have designed a system that would look acceptable (without filters) in emulation twenty years down the road. Despite your and my bias on the subject, I sincerely doubt that displaying these games on a computer monitor ever crossed these company's collective minds.

You doubt? Umm.. the system has RGB out on the back as a valid option. Japanese gamers had access to RGB TVs. European users had access to RGB TVs. US gamers did have the option as well. Even game mags took pics of RGB out. I mean, there's soo much information to support that clean RGB was a viable options directly from the console and the designers who put it there. I don't see how you can say otherwise. That's retarded.

Backward compatibility became the standard in the industry, regardless of your opinion of its importance.

BC is a whole 'nother discussion altogether we don't need to get into. But it's funny how you're trying to link BC nowadays to that of Genesis and SMS. PS1 and PS2, both had extremely successful runs. And you're comparing the pathetic sales of the SMS with that. That's just absurd by itself.

What? I thought the Z80 and the VDP were on the same chip!??? Just kidding. I was throwing out random examples, anticipating you wanting to carve the system up arbitrarily so it could still be "inexcusable" to not add more CRAM.

Well, I don't believe you >_>

RAM on the carts raises the average cart cost and severely limited the sell through of games. I've also seen several executive interviews where they said they had *no idea* if costs would come down *in time* for them. These machines were huge gambles no matter how you look at it.

Well, they're retarded. How was ram ever going to go back UP in price permanently? Every single piece of past history pointed to ALL ICs going down in price. Cost of production, yields, etc.

So I take it you think from year to year all hardware costs came down, and none went up? That's a big assumption.

Duh. If you look at anything in the short term, you're bound to see fluxuations. I don't think 1 year was an expectation of the systems life? I don't why this is even an issue. If price wasn't an issue, then there would be more ram on the system - no? I'm not sure where you're going with this. I stated the problem to the issue was easily addressable. Famicom/NES had been doing this for years on there carts/systems. It only had 2k of system ram. Very popular to have 8k additional on the cart. SNES went even farther with added processor on the cart (SA-1, the rest were just DSP with a hardcoded rom to act as a math processor/peripheral only). 8-24k more than is a cheap fix for the problem on the PCE. SNES, more expensive fix (though still viable). Genesis issue? Not fixable. Can't get any more easier to understand than that.

Right, our opinions weigh the same on this matter, and you don't know the "vast majority" opinion. The only facts are that Sega included SMS compatibility, and NEC did not, which opens up the whole cost discussion. Our individual experiences are only anecdotal evidence, which people can accept or toss out as irrelevant and be just as correct.

Well, at least I've seen more than just the opinions of my friends and school. I've seen this discussed on forums. That's more representative than your end. Never mind the logic of it all. You're trying to justify the expense of SMS BC. Tell me, was it worth the trade off for lower subpalettes? Was it?

Actually, my opinion is that the actual console output almost entirely alleviates the color issue from a gaming (i.e. not developer) perspective. The cost discussion lends context to the relative lack of colors on the Megadrive, which you did not provide before pronouncing it "inexcusable". The way you paint it one would assume Sega had a bunch of monkeys engineering the system and the decision to include more colors was just right their with no other considerations against it. When I pointed out those considerations, you dismissed them, and yet their existence contradicts your assertion.

Hook it up to a RGB monitor and get back to me on that first part As for the second part.. reread this thread a few times over? I don't see how short changing the Megadrive VDP isn't inexcusable in any way, relative to the era, relative to the previous generation, relative to the new comer PCE. >_>

No it doesn't increase the actual colors, but it does have a function, which is what I was pointing out. We both agree that cutting S&L out would not have freed up enough cost to add RAM, I was just pointing out that it is better to have it *in the Megadrive* than to not have it.

Uh, yes it does. S/H hardware and just.. logic by itself, DOES increases the color count. I don't understand how you cannot understand this. It increases the color count, but not detail. Yes, having S/L is better than nothing. But again, along the same lines as the z80 for PCM. It's a poor work around for a much better method. You keep switching back and forth on S/H. S/L doesn't make up for the missing subpalettes like you've suggest it might be used. And no one said simply cutting S/L would be enough to cover the cost for more palette ram. But accumulation of cuts in hardware for more palette ram, S/L should be one of them. S/L isn't exactly cheap. It's not like some line changing thing. It's complex based on priority and layers and combing logic (which needs to run in parallel. I.e. not cheap either).

You completely misunderstood me. I know the PCE doesn't have the effect and so must swap palettes. I was pointing out that certain screens darken and lighten to *to the same effect* in PCE games. Thus the effect had a use in the games.

I'm not sure of the relevance of that, but ok...

This and other examples actually begs a question you are not addressing. With all of the extra palettes "available", why did developers choose to not use them? Your Final Fight and Street Fighter examples expose something that disagrees with your assertion that colors matter as much as you are trying to make them.

Wait, how does that disagree with my point? I thought I was pretty clear. I'm probably repeating myself again for the 6th or 7th time, color count doesn't NOT direct equate to detail in a subpalette system. You asserted this, not me. I've been trying to prove otherwise. Final Fight 35 color VS 36 color proves just this. 1 color difference in count, but almost twice that in detail via color. The SegaCD shot could have had even more colors, like 40-45. It still wouldn't equal that single bitmap color system. I spent I don't know how many hours explaining, providing examples, posting pics, etc - just to show you how the two different systems effect detail. I honestly don't know what else to say to you to make you understand the fallacy of just counting colors (among some of the other illogical assumptions you've made. Like two more subpalettes on the Genesis would equate to the PCE or SNES using 96 colors. That's just ridiculous).

ACD Strider doesn't look as colorful or animate as well as the 8Mb Genesis Strider cart, Riot Zone SCD doesn't look as colorful or as animated as its arcade counterpart or Final Fight CD. Did the developers just not have the competence to make a game for the PCE, Capcom and Westone, really?

Don't lump two different games together. I looked at both games at a low level. I make notes as to what each games is doing. Hell, I've looked at a lot more PCE games than just those two. Why? Because when I eventually got around to coding for the PCE, I was shocked as to why certain things weren't taken advantage of - like on the other systems. I traced through code, cracked compression schemes, etc. I didn't just compare Riot Zone to Final Fight and make some sort of assumption. I did a hell of a lot more than that.

It seems like you're questioning every explanation I have, but without any knowledge on the subject? Why are you so skeptical of me? I've put hundreds and hundreds of hours in coding for console, even just for the PCE. My findings aren't idle speculation. Forgive the analogy, but it's like explaining the in depth mechanics behind an gasoline combustible engine to a layman. And then having my knowledge questioned by that same person. It's annoying. You want answers, I gave you answers. Except you're just cherry picking what you want out of it, and ignoring the rest as it suits you. If you don't trust what I have to say, then I've wasted yours and mine time, and aren't really interested in the truth - just justification for defending whatever your opinion is (matter of fact, a hew your opening threads/post have pretty clearly pointed to this).

If you really want some answers, learn to code for yourself. Learn to trace through the games as I have and understand the logic as I have. Else, observation and speculation means little. You're comparison site isn't going to dither from other inaccurate sites (which we coders tend to snicker at). I'm sick of having to repeat myself and/or having my findings and facts discarded with illogical conclusions or whatnot. I'm wasting my time. You've seen what the PCE can do and the explanations I have given. You really think Strider is a victim hardware limitations? You know what, I am done wasting my time explaining things and discoveries. Someone else can chime in and you can cherry pick what you want from that. Trying to explain technical things to non technical knowledgeable people has got to be the most frustrating thing in life...

See ya.

[sheath]

Right. So to recap my misgivings with the "other side's" approach, I will give the following.

1) Parallax, or "excessive scrolls", is not aesthetically unpleasing or irrelevant because it occurs in real life, and art of various forms mimics real life.

2) A larger palette, or more 16 color palettes available for a single screen, matters a great deal to developers and artists, but must also be placed squarely in the context of what output the artist/developer aimed for.

In the US, nearly all consumers still use RF for these systems (PS3 and Wii only come with Composite to this day). The idea of buying an RGB monitor for the purpose of playing games is incredibly far out of the consumer mind over here.

3) I have new comparisons posted and am constantly revising my approach to this, nearly impossible, subjective subject. I have asked repeatedly in this group of very talented individuals whether anybody had any ideas on how to capture video and audio "accurately" from the stock system's outputs and have received no reply.

[MottZilla]

Two points. Given the relative uncommonness of the PowerBase Converter, I would assume that backwards compatibility is not as big a feature as you think it is. Also, just as you say "everyone you talk to mentions it", no one, not one person I've ever met with a Sega Genesis before 1999 has ever mentioned the Sega Master System, AT ALL. I really think the lack of tons of Power Base Converters shows the low use of the feature. Plus that's a shitty way to have this feature. Could you imagine how much fewer people would have used PS1 compatibility on their PS2 if they found out they had to buy an add-on to enable it?

Next, I don't think the issue is closed that somehow adding more Color RAM was too expensive or costly and that there was nothing they could have done to have added it. I think it's pretty likely they could have added it. It was just a decision they made that from many people's viewpoint was a bad decision. We are talking about a really insignificant amount of memory to add. Even embedded on the chip they could have sprung for it. Unless you can drag out the MegaDrive hardware designers and interrogate them we will never know their reasons why. But it really doesn't matter much what reason they give because I don't think any explanation will say that they simply could not have had more Color RAM.

I think that cutting the SMS backwards compatibility features would have definitely saved on cost enough to boost Color RAM which was important for the 16-bit platform, why would you waste resources on your 8-bit platform that in most markets was not a big success? If they had to cut out the Z80 entirely to save the money for more Color RAM, they should have. It's about spending your limited resources wisely. Spending them on Master System support was an extreme waste. Just like with the PS3 and people complaining about the PS2 support removal. If you had Master System games, you owned a Master System. While it is convenient to be able to play your old games on your new system (with the additional price of the converter) you probably still own your old system. Furthermore if you just invested into the new 16-bit system, you want new 16-bit games. Not the old 8-bit games you've been playing.

It's just a waste. There are atleast rumors that the SNES cut NES compatibility due to cost. It may not be true but the thinking behind it makes sense. Backwards compatibility is an expensive luxury. What if the SNES decided it must have NES compatibility with an adapter, and they had to cut features to get the price down. You might lose valuable RAM or graphical features, even worse maybe Sound RAM that was already limited.

To sum it up, Sega should not have spent 1 cent on making the Megadrive compatible with the Master System. All resources should have been spent on making the best possible 16-bit system they could. It is reasonable to assume that without Master System components taking up resources, there would have been enough to have twice the amount of Color RAM giving Background Planes 4 * 16, and Sprites 4 * 16. Perhaps cutting enough could have even given 12 * 16 color palettes by implying that Scroll Plane A and B would have separate Palettes along with another for Sprites.

By the way about RF output. Just because you think most users had shitty RF output doesn't mean it makes the low amount of Colors OK. The NES and SNES were on RF too. The same players that played SNES in RF and Genesis in RF still noticed the much higher color count on SNES.

[sheath]

Two points. Given the relative uncommonness of the PowerBase Converter, I would assume that backwards compatibility is not as big a feature as you think it is. Also, just as you say "everyone you talk to mentions it", no one, not one person I've ever met with a Sega Genesis before 1999 has ever mentioned the Sega Master System, AT ALL. I really think the lack of tons of Power Base Converters shows the low use of the feature. Plus that's a shitty way to have this feature. Could you imagine how much fewer people would have used PS1 compatibility on their PS2 if they found out they had to buy an add-on to enable it?

It is actually irrelevant at this point, but my statement was that everybody I have talked to who owns a Genesis considers the SMS compatibility a significant feature. At this point you and I, and Tomathieous have failed to prove anything about this topic. We have three opinions, with three sets of anecdotal evidence. That is all.

Nobody gets to say that everybody, or most people, do anything on these topics without actually performing a survey and providing the relevant data collected by said survey. To disagree with this point is to claim your own experience is more important than anybody else's experience. The matter of backward compatibility's relevance is entirely subjective.

Next, I don't think the issue is closed that somehow adding more Color RAM was too expensive or costly and that there was nothing they could have done to have added it.

I'm with you here, but without actual interviews, or cost sheets from 1987-88, we cannot go any further with this topic. My only point was to disprove the "inexcusable" assertion. Now that we have many excuses that nobody can invalidate, my point is made.

Without more facts, the discussion is at a stand still at the following conclusion: the MD/Genesis configuration probably cost enough to make the possibility of additional CRAM fiscally irresponsible to those parties involved in the original decision.

(snip conjecture about SMS compatibility)

By the way about RF output. Just because you think most users had shitty RF output doesn't mean it makes the low amount of Colors OK. The NES and SNES were on RF too. The same players that played SNES in RF and Genesis in RF still noticed the much higher color count on SNES.

You are missing my point on this entirely. My point begins and ends with the fact that game artists were not aiming for computer monitors or HDTVs when they designed any of these games. Thus, most of the "obvious" color issues are explained by the fact that they were not so obvious on the target output.

Do you not think that, if monitors and HDTVs were the target, the original artist might have focused more on creating a higher color image?

[MottZilla]

I think good evidence on the SMS compatibility would be to find sales figures if possible, for the Power Base Converter, by region if possible.

I think it is fiscally irresponsible that they wasted resources on SMS compatibility. It may be an opinion but there is a valid point there too.

I see your point that RF sucks. And that RF has it's own issues that distort colors. But you can't have it both ways. Both PCE and SNES were commonly played by RF and they didn't use that excuse to use less colors.

[tomaitheous]

I think good evidence on the SMS compatibility would be to find sales figures if possible, for the Power Base Converter, by region if possible.

I think it is fiscally irresponsible that they wasted resources on SMS compatibility. It may be an opinion but there is a valid point there too.

I see your point that RF sucks. And that RF has it's own issues that distort colors. But you can't have it both ways. Both PCE and SNES were commonly played by RF and they didn't use that excuse to use less colors.

You really need to visit his site and read the VS system pieces and also just take note of the system specs he's listing He's counting colors in composite capture shots! That's part of his scientific method as he calls it ;>_> His specs are off on the consoles (some dubiously so) and clearly has a thing for Sega VS Nintendo. Definitely a SMS bias in his SMS vs NES read. Same for SNES (he still has it listed that the SNES is limited in color capability when doing "scrolls" and only lists 2 BG layers when lots games actually used mode 1).

Hadn't visited the site in a couple of years.. so I checked it out again.

Some funny stuff:

The Sega Master System trumped the Nintendo Entertainment System in every possible technical respect.

Yeah, ok :rolleyes:

Ongoing favortism for the NES leaves no need to reiterate what is stated on other video game related web pages. Bias clouds the perspective of editorialists and fans from realizing that the NES library only surpassed rival console libraries after the 16-bit generation was in its stride.

-_O;

NES audio: "Audio: 4 Channels" <- It's 5. And it's lot more complex than what the SMS puts out.

SMS sprites: "Sprite Max & Size: 64 at 32x32" <- It's 8x16 for max, just like the NES.

NES colors: "Colors On Screen: 16" <- It's 25 without tricks.

NES palette: "Color Palette: 52" <- technically it's 400+ in 52 section segments. Yes, a few games change the master palette emphasis bits.

NES vram: "Video RAM: 2KB" <- he forgot the 8k of VRAM/VROM on chart. Or the fact VRAM has direct mapper support which easily extends this. Swapping out banks (midscreen or not) is faster than any of the 16bit consoles too.

NES ram: "RAM: 2KB" I'd say probably close to half the NES/FC library uses the addon ram for a total of 10k.

He rounds up 3.579mhz to 3.6mhz on SMS listing, but only rounds up the NES from 1.789mhz to 1.79mhz. Yeah, just coincidence

Some others:

TG16 res: "RESOLUTION: 256x224 || 320x224" <- 256x240, 344x240, 512x240. It also allows res into overscan for 288x242,384x242,576x242.

TG16 audio: "Audio: 6 Channels PSG (Uses CPU)" <- it's not "PSG". It's a little more complex than that And uses CPU? Not sure if that's particularly making some sort of connection because it's on the CPU die or just means there's no dedicated sound "processor".

TG Duo audio: "6 Channels PSG + CDA" <- Forgot "+ADPCM channel" with it's "own" 64k of sample ram (not part of the system card ram).

TG Duo co-processor: "CD-ROM Processor: 16 MHz 65802" <- no such thing exists. It has an peripheral MCU on the CD base side, but no 65802. Not a processor or co-processor in anyway. It just redirects port writes to ADPCM ram, and allows you to read a sector of data at a time from the CD data track (again, I/O). Not sure where this rumor/fact got started, but it sucks when people list his site for this info in forums.

TG Duo ram: "RAM: 256KB (Super System Card), 2MB (Arcade Card)" <- it's technically 262k of ram (don't forget the 8k onboard), but ram doesn't serve a purpose on the CD unit as it does on the cart units. All it does it simulate cart space for that given instance. Even more so with ACD memory. ACD memory is ALL port based. Nothing local or logical mapped. Games that reserve bits of memory for traditional "ram" use usually do 16k to 32k of ram but only if they are using compression in "cart space" (on SCD, CD 2.0 games don't do that). If a game doesn't use compression, it only uses the 8k of system ram (because there's no need for the additional "ram").

TG Duo colors&palette: Both have max color listings, but also have additional info about colors per tile and sprite (which is dubious because what one considers a sprite could be in fact a pseudo sprite with multiple parts being from different SAT entries). None of the other systems have this additional accompanying info.


Genesis res: "Max RESOLUTION: 320 x 224" <-not technically the max (320x448 is), but why isn't the low res mentioned too? It is on the SNES and TG/Duo. Should be listed at 256x224, 320x224, 256x448, 320x448.

Genesis sprites: "Sprite Max & Size: 90 at 32 x 32" <- it's 80 and only in 320x224 mode. It's 64 entries in 256x224/448 mode.

Genesis colors & palette: list as 64 colors while TG/Duo listed as 482. Either put 512 for the TG/Duo or fix Genesis to 61.

Genesis BGs: "independantly scrolling 8 line rows, or independantly scrolling lines." <- Addition specs listed, but none for TG/Duo which has the same capabilities.

Genesis hardware: "Software sprite tilting and warping
Limited flat-shaded polygons" <- software sprite titling? WTF? Limited flat-shaded polygons? WTF? Every cpu is capable of "limited flat-shaded polygons". I think he's read too much EGM. No idea where sprite titling came from.

Genesis: "3.58 MHz Z80 (Sound or Graphics), TI 76489 (PSG), Yamaha YM 2612 (FM): 10 Channels" <- somehow the CPU got slower (not 3.6mhz). The PSG *and* FM chip are now co-processors but the audio chip on the SMS, NES, and TG/Duo aren't??? And the FM chip magically has 10 channels now.

Genesis audio ram: "Audio RAM: 8KB" <- calling it audio ram is really a bit of a stretch.

SNES res: "256x224" <- should be 256x224/240, 256x448/480, 512x224/240, 512x224/480. With a note that 512 horizontal res mode is only for the BG layers, not sprites.

SNES res: "Max RESOLUTION: 512 x 418 (16-color)" <- what? Why is this listed as 16 only???

SNES video ram: "Video RAM: 16 KB" <- yeah... not quite. 64k

SNES colors: "256 (single background), 90-150 (4 backgrounds)" <- never mind changing between MODEs via HDMA, 90-150? Also, what about direct color mode+palette (the so called 2048 color mode)? And why list 90-150, when it should be either 241(like TG/Duo 482 <- which should be 481 actually) or plainly as 256 like he lists 64 for Genesis. Very inconsistent through out all the systems.

SNES sprites: " 60 at 64 x 64" <- ehh? It's 128 entries regardless of the size. Not sure where that number was pulled from >_>

SNES BGs: " 4 (5 in some Software)" <- 4 but 5 in software!? And yet the TG/Duo also has 5 in software but on 1 hardware BG layer? Yeah, them "apples to apples" don't add up. I don't follow the logic, but listing the max is a big unrepresentative of the SNES. 3 is the most common mode(1). I think only a few games use 4 BG mode (0).. actually I only know of one, but I'm sure there's at least a couple that have used it to at least some extent.

By the time of the SNES' release, the Genesis had overcome its 64 color limitation by using shadow and lighting effects and swapped color palettes.

Not really true at all (*chuckle*). No mention of the SNES transparency boosting "color limitation" either.

Later in the Genesis' life cycle developers were employing methods for using the NTSC format's blurring effect to blend pixels into effectively displaying 128-256 colors on screen.

OMG D: And there it is! Confirming the "256 color" mode of the Genesis via RF/composite. That makes EVERYTHING else about the site immediately suspect. Sigh...why do people try to justify/ add validity to this purely made up marketing thing?


This...

The majority of the NES's vastly larger library, and its lead in notable game titles, was gained after 1989, when the 16-bit era had already begun and the NES was the only mass market 8-bit platform.

Using US names mean US systems. The 16bit consoles barely started in the end of October of '89. Unless he's referring to the Japanese 16bit consoles, but one would also have to include the MUCH bigger Japanese FC titles that didn't come out here. The point is incorrect either way.

More funny stuff:

What constitutes a perceivable color count difference is debatable, but the SNES was limited to 2 background planes and 1-2 foreground planes if it was going to display 90-120 colors on screen, 2 planes if it was displaying 256 on screen with 16 color character sprites

lol

Both the Genesis and SNES were limited to 16 colors per character sprite in most games, most notably Street Fighter Turbo and Super Street Fighter 2.

Need to comment on this. I think this is an attempt the make the Genesis limitation less effecting overall. He also mentions SF2 ports. Yes fails to list that the arcade itself also have the same 15 (not 16!) color limit. The CPS1, the Neo Geo, etc. Lots and Lots of arcade systems had this very same limitation. But with one exception... lots and lots and lots of subpalette ram and some even with small master palettes like the CPS1 (oh, imagine that - similar to the PCE. Must be coincidence ).

Genesis could display 2-3 times the sprites and independently scrolling 2D planes.

Another "lol". Not to mention, he NEVER mentions sprite pixel scanline limit or sprite cell to pixel scanline limit. Both having very direct effect on onscreen graphics/sprites. With the SNES having the best case in both those areas out of the three systems. But oh no, Genesis could display 2-3 times more sprites. Yeah...

"tilted" sprites

Again with the tilted sprites?

(Genesis) featured more custom special effects like scaling background

More? Clearly doesn't know the sPPU of the SNES.

The Genesis' software effects are best seen in Contra Hard Corp, Castlevania Bloodlines, Batman and Robin, Ranger X, Sonic 3D Blast's bonus levels, LHX Attack Chopper, and Red Zone, for starters.

I wouldn't say "for starters". That's a pretty big chunk/most of the list right there.

Regrettably, popular history uses the same measuring stick for all success stories. Sales is what most ill advised people look to in order to validate or invalidate their purchase decisions and sales is what the media is biased towards.

Having grazed the internet for some time, I've come across this myself lots of times. And the vast majority of times, it's the Genesis fans bringing up sales numbers (and by that, I mean "fanboys"). They are obsessed it for some reason. Be it on multiconsole forums like DP or Genesis only forums like Sega-16. SNES fans are more like "yeah, snes was really popular" and then just move on. Genesis fanboys are always adding numbers, using specific dates, and such. Gets really complex. The funny thing is, is that these numbers don't even seem to have a valid point of origin. Let alone these numbers were for share holders and investment companies . As in companies tend to fudge numbers to make themselves look better to their bosses (share holders/investors). They the "fans" start making claims like "you can't trust company X" etc. Very funny to observe. I even got an email asking for TG and PCE numbers. As if I'm supposed to have all these facts for TG/PCE. I don't want any baby-momma drama nor am I the ambassador for TG/PCE land >_> I'm just a coder and a gamer. Though... I wouldn't mind being Ambassador DVinn.

Anyway, I thought the site was getting a revamp. Looks like it just the page/graphical/layout itself and not the content. Great, more continual linking to miss information

[MottZilla]

Don't worry Tomaitheous. I am aware of how biased he is and how he goes about making his argument. It's kind of sad when people let some sort of brand alliance cloud their reasoning. While I grew up with NES and SNES, I never had an animosity toward Sega Genesis. Similarly during N64 and PS1, I never owned a Saturn but I didn't hold anything against it.

I appreciate the systems for what they are and don't pretend they are anything different. Anyway, I was just pleased to see someone, even someone I'd already met before , agrees with my opinion on the Sega Genesis Palette issue. Also I found it interesting to suggest that it may have had more Color RAM that was cut, rather than before I assumed it was never there to begin with.

[sheath]

The spec sheets are cited, I am not making anything up, merely trying to simplify.

Okay, specs are off, which ones and how so?

And no, I don't take the word of somebody who resorts to personal insults in a discussion. You will have to provide proof from now on.

[ob1]

Well, it seems to me that the debate as long gone away from colours count per screen, so I will have my few points :

- I think (and that's only my opinion) that backward compability became relevant only later. There and then, backward compability was quite a new feature (brought by the PC world), and manufacturers got interested in it 2 generations later (PS2). I don't recall Nintendo thinking about backward compability for the SNES, but Sega questionned about it for the Mars/Saturn project (Neptune is a good illustration). But I am sur Nintendo intentionnally dismissed it for the N64, citing cost (the console would be too expensive) and technology (the architecture would be very bad).
Backward compability is, in my point of view, a mere marketing point. Sellers tell customers that they can keep their old game, so the new machine is not that expensive. Whether backward compability keeps customers going away is out of my knowledge.

- I don't think (and that's only my opinion) the Z80 was there for backward compability ; at least, solely for backward compability. When you look at Sega arcade systems, you can clearly see that they've used the Z80 for a very long time (since 1981, G80) and moreover, they've used it as a sound CPU for a very long time too, especially for the System16. And it seems to me that System16 is the frame of the Genesis. As wiki states, the same architecture was used for CPS1, CP2 and NeoGeo. It seems to me that the 68k/Z80 was the canon then, just like ARM today is (Gameboy Advance, DS, GP32, iPod, iPhone, iPad ...) .
"Hey, moreover, we could use the Z80 for backward compability !". Great ! Build a big ugly Power Base Converter and sell it ! That will be another selling point for our new Genesis. Mottzilla is true : we would have to bring a Genesis architect here !

- more CRAM. The VDP has 40 10-bits words of VSRAM and 64 9-bits words of VSRAM. So, adding another, let's say 64 words inside of VSRAM, is adding more than 50% of embedded RAM. I can't find any evidence supoprting or denying this hypothesis. Looking at the mere TMS9918/A, it lacks (a lot) of CRAM. Looking at its "successors" (YamahaV9938 and 9958) doesn't raise more answers. So, we can't say that the mere TMS9918 did/could have more CRAM. But, Genesis VDP was an ASIC, a TMS9918 modified by Sega. So, could Sega put more CRAM ? Did they want to ?
Then again, I look at Wiki and system-X (1987), which has 4 layers (right, they'r on VRAM), but if there are more layers, there may be (may, only may, since I don't know anything about System-X VDP, especially whether VScroll data was in VRAM) more VSRAM.
I then remind the NES, where colors were limited to 52 (Myamoto was asked to choose which ones).
All in all, I don't have any clear clue.
So I believe, and that's only a faith, that Sega could have put more CRAM, but they didn't want to, for cost reason (sell the console at a higher price or have less margin). For the real, true, actual reason, once more, we would have to bring a Genny engineer. But does that matter that much ?

I'd like to add that this topic is full of knowledge, of teaching of how a VDP runs. I've told tom' that I found its work amazing, especially the ones on color "reduction".
OK, and there are trace of anger. Please gentlemen, we can/should be better than that.

[tomaitheous]

The spec sheets are cited, I am not making anything up, merely trying to simplify.

Okay, specs are off, which ones and how so?

And no, I don't take the word of somebody who resorts to personal insults in a discussion. You will have to provide proof from now on.

Yeah, cause you'll take specs from sites with obvious conflicting specs from one another - but don't take the word from someone who's coded on the consoles. Nope. That makes perfect sense. That's some sound logic for you. I'll provide no more proof (funny thing is, none of those sites have "proof" either, but I guess just being on the website is all the proof one needs?). You can learn to code on these consoles for yourself get definitive proof. Or not. I've already provided proof on things and along with sound logic, only to have it through right back at me. That tends to irritate me. I know someone out there is having a laugh at my expense I should have just stayed away from this thread. To be honest, you are of special interest for me. I've seen quite a few people use your site as reference for spouting specs. And now I see it's just a redirect of other miss-information from other sites. Yay! You originally said you were going to.. I forget the exact words, but something to the effect about getting the facts straight and what not. Well, the "not" is correct for the most part. I dunno, maybe it's impossible to put such things in comparison with layman terms, without really understanding the underlying hardware intimately (as in your case). Still frustrates me because you're gonna walk away with nothing really changed. I love a good comparison like just as much as the next guy. There's always gonna be a little bias towards a system/game/genre/whatever, but as long as it doesn't get too much in the way - it's easy to over look. This is not what I get from your site from what I've read/seen. It's my gut feeling is that its going to remain validation site for fanboys to turn to when they can't get what they are specifically looking for other comparison sites that don't exactly align with their opinions. It happens. Not everyone is in the technical know, and it's easier to just reference some site as "proof" of whatever and be done with it.

I admit, I still go to such sites. Not for the comparisons, but to find stuff directly about that systems games. Those are probably the best type of sites for that. You can find the hidden gems of the systems and what not. Fans know their systems inside and out. For instance, I'm TOTALLY in love with the Speccy. I'm not from the UK or EU. Never owned one. Never played one even. Never even scene one in real life. But I just love looking/watching these impressive examples of games that, technically, should not even exist. I mean, if it weren't for such loyal fanboys of this system - these softs wouldn't have existed in the first place. The extremely limited specs of the system never stopped devs from making amazing ports for it (relatively speaking). The system never ceases to amaze me. It's got soo much charm to it. One of these days, I'm gonna get one.

Got to mention, that "A brief history of home video games" site from your reference links - is hilarious. Reading that, I wholly believe that guy/girl never experienced the 8 and 16bit generation for their self (or maybe they have some sort mental disability. Could be that. Or maybe just bad memory). It's as if the author took pieces of information he found on a forum (cause you get ALL kinds of random spewed bullshit on forums) and revised history. I especially love the part where Nintendo helps out NEC and the "turbographix" because Sega is getting the upper hand with the Genesis. Bwa-hahahahahahaha. I really did laugh out loud on that one. Oh man, funny ass read. Thanks for having that as a reference on your site.

I appreciate the systems for what they are and don't pretend they are anything different. Anyway, I was just pleased to see someone, even someone I'd already met before Wink, agrees with my opinion on the Sega Genesis Palette issue.

You never finished that Contra port either!

[tomaitheous]

- more CRAM. The VDP has 40 10-bits words of VSRAM and 64 9-bits words of VSRAM. So, adding another, let's say 64 words inside of VSRAM, is adding more than 50% of embedded RAM. I can't find any evidence supoprting or denying this hypothesis. Looking at the mere TMS9918/A, it lacks (a lot) of CRAM. Looking at its "successors" (YamahaV9938 and 9958) doesn't raise more answers. So, we can't say that the mere TMS9918 did/could have more CRAM. But, Genesis VDP was an ASIC, a TMS9918 modified by Sega. So, could Sega put more CRAM ? Did they want to ?
Then again, I look at Wiki and system-X (1987), which has 4 layers (right, they'r on VRAM), but if there are more layers, there may be (may, only may, since I don't know anything about System-X VDP, especially whether VScroll data was in VRAM) more VSRAM.]

Something that never really came up, was that the original VDP (and on a few models after the first), that the VDP had serial output. A digital bus. 10bits IIRC because it has S/H status bits. Anyway, you can also easily detect sprite pixels from BG pixels on the bus - by checking the corresponding bit is set or not. Sega uses this method in their arcade boards too. PC-Engine in fact does exactly this to get a separate 256x9bit color palette ram just for sprites. So, that was another option.

As for the internal CRAM, I can't remember all the details - but I know this was what tipped me off originally:

The VDP has 64x9 bits of on-chip color RAM. It is accessed as 64 16-bit

The address register wraps past address 7Fh.

From Charles Macdonald's genvdp.txt doc. I think there was some patent reference stuff too, but I don't clearly remember all the details (this was discussed much over a year ago between him and me). Anyway, the idea was that if it wrapped at 0x7f and not 0x3f, then why would they do that if they had no plans on using ram in the 0x40-0x7f region (i.e. you only need 0x3f WORDs. WORDs being 9bit in length on chip). That was the question that lead to the discussion. And I believe there was talk here about this too.

I then remind the NES, where colors were limited to 52 (Myamoto was asked to choose which ones).

Never heard that before. I do know it took quite a while for people to figure out that the NES PPU was using HSL system. As in the color # you chose has direct bits through out that value that effect H/S/L. And thus you have a logic layout of colors, rather than something random like C64 (disregarding the half intensity set of 8 ). And that the three "RGB" emphasis bits (or de-emphasis bits, depends on how you look at it) are also added overall to each HSL bits to create the final output. Thus, the 400+ color master palette, but only in 52-54 color segments.

OK, and there are trace of anger. Please gentlemen, we can/should be better than that.

That would be my frustration, but I'm done directly trying to help him understand. Plus, maybe somebody else could chime in with some fresh ideas or such. Like you have Instead of this back and forth stuff.

[Eke]

Something that never really came up, was that the original VDP (and on a few models after the first), that the VDP had serial output. A digital bus. 10bits IIRC because it has S/H status bits. Anyway, you can also easily detect sprite pixels from BG pixels on the bus - by checking the corresponding bit is set or not. Sega uses this method in their arcade boards too. PC-Engine in fact does exactly this to get a separate 256x9bit color palette ram just for sprites. So, that was another option.

actually, the color bus is already limited:

/Y1 : 0= Transparent pixel, 1= Opaque pixel
SPA/B : 0= Sprite pixel, 1= Non-sprite pixel
VD7 : Hilight effect (0= not applied, 1= applied)
VD6 : Shadow effect (0= not applied, 1= applied)
VD5 : Palette, bit 1
VD4 : Palette, bit 0
VD3 : Pixel, bit 3
VD2 : Pixel, bit 2
VD1 : Pixel, bit 1
VD0 : Pixel, bit 0

still there are only 2 palette encoding bits per tile available in the 2 word (16-bits) pattern description , this would have required a whole revamped VDP logic I think. They could have dropped shadow/highlight bits for 2 additional palette bits but still you need the extra hardware for the color bus decoding, CRAM access from CPU, etc. The idea was probably to produce a mass product, not a boosted arcade system.

From Charles Macdonald's genvdp.txt doc. I think there was some patent reference stuff too, but I don't clearly remember all the details (this was discussed much over a year ago between him and me). Anyway, the idea was that if it wrapped at 0x7f and not 0x3f, then why would they do that if they had no plans on using ram in the 0x40-0x7f region (i.e. you only need 0x3f WORDs. WORDs being 9bit in length on chip). That was the question that lead to the discussion. And I believe there was talk here about this too.

It wraps at 0x7f because CRAM size is 128 bytes (0x80) to hold 64 (16x4) color values , each taking 16-bits in memory (as CRAM bus is 16-bits wide) so 0x40-0x7F region IS used by colors 32-63 . There is no wasted memory in CRAM other that those unused bits in each word but still, you could never have fit two 9-bits color value in one 16-bits word... ouch, my head hurts

[Stef]

CRAM wraps at 0x7F but we're speaking about word adressing (so we can acces to 128 words in theory).
I remember in early version of Gens i assumed the wrap was done at 0x3F because Genesis only have 64 CRAM words but i got some palette bugs with Batman and Robin (DMAing too far in CRAM). Also as we explained before the 2 bits palette addressing in tile isn't a problem in we have 4 palettes for BG and 4 palettes for sprites (SNES and some others machines does that). It's not as good than having 8 overall palettes but still a lot better than having only 4 overall palettes.