SpritesMind.Net

I can't find any such reference to a 7.16 mode, especially one used in game. 7.16 is conspicuously two times 3.58, and the PCE/TG16 community has been known to try to claim that the 3.58 Mhz Hu6280 sound processor could be used in tandem with the CPU (thus doubling the processing capability). This is not the case.

Similarly, early reports of the Sega CD claimed that its 12Mhz 68000 could be used to effectively double with the Genesis's 7Mhz 68000 to make a "32-bit system".

In short, I would have to see games that are demonstrably using this 7.16Mhz mode for the PCE before I'd believe it. Every indication and every other source says that the two Hu6280s are a CPU and Sound processor respectively that have never been combined.

Two HuC6280s? I've never heard of the TurboGrafx having two of them. AFAIK the HuC6280 contains both the CPU and the sound circutry (and some other stuff) in one package, much like the 2A03 that was used in the NES.

Well, it appears as though I've been mistaken for quite a while about the Hu6280. I must have misread the FAQ, and/or misunderstood how numerous fans/programmers referred to the CPU in the first place. There is something truly strange about this though, as I recall the 3.58 Mhz rating on the box specs of the TG16, and have seen it for nearly two decades on Usenet and online FAQs as having two seperate 8-bit processors. I even recall detailed discussions fairly recently that finally disproved the idea that both 6280s could be used in tandem. The discussion was akin to the Saturn or 32X SH-2 discussions over the years.

I'm going to have to do some digging on Usenet and print magazines to see where I went wrong. 7.16 Mhz, really, wow.

I can tell you first hand that the CPU is running 7.159mhz in high speed and 1.79mhz in low speed. It's *always* running in high speed unless it's accessing BRAM, which NEC states should be accessed at low speed (although I've had no problem accessing it in high for tests). Besides my own tests I've done (Timer IRQ, opcode loops, a counter, then to the display), Charles Macdonald did his own tests as well, and the official documentation (as well as Develo ) also state 7.159mhz. There's definite no question about the speed, it's just that some sites really have some incorrect info. I think I've seen some sites still listing it as have two 8bit processors @ 3.58mhz. That's ridiculous and thank god it doesn't. A single processor at double the speed will always be faster than two at half speed. The only game that I know if that uses 1.79mhz mode other than for BRAM, is Super Star Soldier. When it does idle loops during active display, it puts itself into that mode. The only benefit we can see, is that it uses less power when running the game in the Turbo Express portable TG16.

Updated the previous post regarding TG16 sprite sizes with:
16×16, 16×32, 32×16, 32×32, 32×64

16×16, 16×32, 16x64, 32×16, 32×32, 32×64

It would certainly explain how the Arcade Card games managed to pull of their amazing visuals though.

The speed was always there, the Arcade Card just gave it the memory to handle the animation. To put the CD unit back to a cart competitive level for the time. SF2 was done on hucard specifically because Duo or SuperCD 3.0 didn't even have half the memory to handle that game. SuperCD, while better then original CD 2.0, was still starved for memory relative to SNES and Genesis carts. And add to the fact that most developers didn't even bother with compression schemes, only made it worse. You don't compress for CD space reasons (that's obvious), you compress because you don't have a small amount of ram to simulate cart space. You can't just randomly grab stuff from the CD drive when you feel like it, it side the game - that's too slow.

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.

Doesn't work like that. You don't lump vram in with work ram. VRAM is completely cut off from the CPU on all three systems. And it serves no purpose to the CPU, other than when it wants to update some frames. The CPU has to give a byte or word to the display device and the display device puts it into vram, and the opposite if you're reading out from vram to the CPU.

Work ram is definitely direct comparable though. 8k is too little. If you have no compression schemes to worry about, you get by fine with 8k. If you don't have any compression schemes, then you have no need to buffer any tiles/sprites. You would just read it from rom instead. In the case of the PCE (for hucards), programmers chose bufferless friendly compression schemes that would take almost no ram. RLE/RLZ(mask) type stuff. But that stuff never compresses very well at all - but you still get the overhead of decompressing it. Some hucards went the 3bit route. This gives you automatic 25% cut in size and not decompression overhead (you just "pad" the last bitplane with zeros, but most of the time you don't even need to do that! VRAM already has that bitplane cleared). The down side of 3bit graphics cells is 8(7) colors. While I was able to do LZSS+ decompression with a small ring buffer with awesome compression results, no of the other developer did that. So I would definitely agree, only having 8k of ram directly effects the game.

Two things to note; Street Fighter 2 CE only used 8k of ram because it didn't need anymore than that, because all sprites were uncompressed. And the other thing, ram can be easily added to the cart to make up for the single 8k bank of the original system. We didn't see this in SF2 because it wasn't needed and we didn't see this in other hucards because the CD format quickly dominated and became the main format, with the hucard format becoming the subformat (some softs developed to specifically legacy users and for PCE GT users - or Turbo Express here in the states). One hucard did add additional ram to the cart - Populous. It added 32k of ram to the cart.


You're write up is fairly good. I would change a few things:

16x16 16 color palettes. You're notation is a little funny. I would change that to 32x16 (which is how it's usually described, even on the GBA and NDS) or 32x16color palettes.

CPU: 3.6mhz. Change that to 7.16mhz. For the PCE video processors, if you're going to mention that it has two - then you should probably mention that the second one shouldn't really count as a "graphics processor". It only builds the NTSC "frame" and timings, handles filtering, and handles external to the VDC palette ram (as opposed to the Genesis VDP handling it internally). The names are as follows: the "VDC" is the graphics processor also known as "7UP" (like the soda) and the VCE is the second 16bit device also known as "TETSU or 鉄観音". Not that it matters much, but the CPU also has a nickname "Dr. Pepper" or "DRP" for short. The SGX has two 7UP's and new chip priority chip for them called "PATTY". I dunno, the nicknames might not really matter. Just a FYI for the curiously minded.


For the Genesis, I would really focus on the sprites. IMO, it's thee strongest attribute of the whole graphics system. It has the best configuration for optimizing against sprite drop of the three system. And the ability to update the sprite table mid screen for some neat effects. Features like S/H, which given the library size, are more rarely used and definitely don't have an impact like the sprite capability has. As far as the linescroll, every system can do it. If you're gonna list *that* on the Genesis, might as well on the PCE and SNES. And I would argue that both the PCE and SNES have a more flexible and less overhead method for doing it than the Genesis (in both methods for the Genesis. Be it scroll block or H-INT overhead of the 68k). Also, the column scrolling (16 pixels wide) would be an FX that I would point out. More so than the S/H. It's practical in application for vertical scrolling (think MUSHA's canyon or other games that use it like that) and such. A few games use it as "titling" too, but I think just for vertical parallax is the most important use of it.

Listing the z80 as some sort of video related processor, is pretty much absurd. As a benefit. More absurd than trying to point out the importance of Shadow/Highlight. While one game might have used it (and you have no idea as to the efficiency of its use either) doesn't really make it an asset. From what I take it, you're listing practical attributes of the systems that were put in use, right? Not demo or exploits learn many years later (or have an extremely limited use). While they maybe worth mentioning (TmEE's PCM driver is definitely something that should be mentioned), such things should not be listed as main attributes to a system. At least, not in my opinion. If you go that route, I could give you a ton of stuff on the PCE - with most of it never done in official games. Or even bizarre features of the SNES sPPU.

Some specs:

PCE

CPU: HuC6280 7.16mhz custom cpu based on Ricoh's custom 8bit 65c02
Graphics: HuC6270 16bit video chip + HuC6260 16bit converter/color chip
Ram: 8k base work ram
Video ram: 64k

Strengths:
- Can fully write to vram at anytime of the display (other systems are very restricted or off limits).
- Tiles and sprite can be located anywhere in vram (including the SAT as well)
- high customizable video settings. You can do split horizontal screens, or multiple (more than 2) vertical screens - each with their own 64 sprite table.
- Has huge amount of subpalette ram for complex image detail or more simultaneous colors.
- Has fairly large sprite sizes
- Has buffering of registers for easy of use linescroll effects (both X and Y effects) and a programmable horizontal interrupt controller (can called on up to all 262 scanlines).

Weakness:
- No tile flipping. This makes vram tile usage more flexible when you have simple patterns that you can exploit. A lot of early games where designed like this.
- no second BG layer. That means very large enemies/bosses have to be done with sprites on the PCE, VS BG layers than the Genesis and SNES use very-very often. It also means certain type parallax effects aren't directly doable (or even at all) and require dynamic tiles (more cpu overhead, more space overhead, more vram storage overhead in <- in some cases).
- Given the enormous amount of subpalettes usuable, the master palette should have been larger than 512 colors.

The PCE and Genesis share some attribute in common that the SNES does not. Both system can have sprites anywhere in vram. The same goes for tiles. And the same goes for the SAT. For the number of tiles/sprite - you're only limited by the amount of vram. The SNES is restricted on where tiles and sprite must go (and the total amount you can have) and is divide across a bank system. The SNES SAT is also fixed in location. The PCE and Genesis can use any size sprite of the configuration table at any time onscreen (all of them can be used in a single frame). The SNES is limited to only two sizes at a time for screen (a common configuration would be 8x8 and some other size. The more usage of 8x8 makes the 128 wide SAT more applicable than just a number or advantage).

As for subpalettes: I have some example pics I and graphic artists were working out..


This pic was originally from the SF2 PCE port. We modified it by adding some missing detail back into the BG. Keep in this, this pic is still 100% PCE legal. Even right down to the size required for the game (vram space). The pic only counts up to ~62 colors total, but it used 14 subpalettes! I think the original pic was in the low ~50 range. These two pics show you what subpalettes are used for which 8x8 area:





In that pic, I think we went from 8 subpalettes to all 14 subpalettes. (Left is the original BG layer).


From left to right: PCE original, SNES, GEN, PCE upgrade

Here are some pics showing the Genesis subpalette limitation:

PCE left, GEN right. The Genesis version isn't getting any benefit from the additional res either, in that pic.


SegaCD left, PCE CD right. This time, no res increase. And Lords of Thunder hardly pushes subpalette usage on the PCE.


Sega left, PCE CD right (Both pics are scaled to correct PAR with nearest neighbor to remove any blurring for scaling). I tried to get a pic that shows the Genesis in a little better light, so to speak. The PCE pic is pushing 94 colors in that instance, but isn't pushing that hard on the subpalettes. That PCE pic would easily be in the 120-130 range if the PCE had a bigger master palette. If you looked at the whole BG, the PCE BG layers actually has more colors/details than that. There's a part with a small depot that scrolls by (small for a depot, large in the pic):

Subpalette limitation also apply to unseen parts of a BG as well.

The subpalette limitation is pretty apparent to me on the Genesis. I've noticed it in LOT in two spots that come to mind. The sand level with the giant serpent creature. They sand lion type enemies that normally pop up before, during, and after said create - don't in the SegaCD port. I believe is this directly done because that create would require more unique colors that what was allowed configurable for that window at that time (because things tend to be somewhat dynamic in games, you need to allow for certain enemies that use certain parts of some subpalettes). Another is the last part of the fire level. They blank the far back layer for a long period of time, when the PCE one only does it for a short period of time (talk about the foreground collapsing/moving/changing while the fade the far pseudo BG to black during this). Since there's a lot of different enemies in that spot, it also appears to be a function of limitation.

Some more examples (pce left, gen right)..




















Quite a few pics with the Genesis version having higher res. Judge for yourself if you think the higher res is doing much to make up for the color/detail loss. I personally don't think it does. (Also, I picked the best shot I could find of Forgotten Worlds on the Genesis, because normally that game has horrible graphics)

Some PCE,SNES,Genesis 3way comparison shots:






All Compile games. The PCE is actually a CD 2.0 game. None of these games are late in the systems life.
(Sorry, don't have a non flashing pic of the last boss on the PCE one)

About your comment of colors and scrolls, I assume you mean something like this?














Nice colors, not *much* scrolls (sometimes none at all). While I've already explained the limitation of the PCE, I didn't really explain the tricks it uses to get around that. Dynamic tiles are one those tricks (in conjuction with linescrolling). Some of those pics are setup perfectly for dynamic tile situation. Why they didn't use it? I'm not really sure. Strange that they really have seem to be setup for it too. I mean, too much of a coincidence. And it's a later gen game, though it seems to be a running occurrence with PCE developers. Only a few design a game that far out, for such a dynamic tile/etc method.

And for the people not really caring about this thread, you can at least enjoy the pics

mic_ wrote:Two HuC6280s? I've never heard of the TurboGrafx having two of them. AFAIK the HuC6280 contains both the CPU and the sound circutry (and some other stuff) in one package, much like the 2A03 that was used in the NES.

EGM was responsible for that crap! The magazine couldn't get its fact straight for anything. It was a very popular mag over here in the states and stated that on a few occasions about twin processors. Other system specs were mangled as well.

sheath: Usenet is bad source of information pertaining to specs (and even other stuff). Though I admit it's fun to read those really old posts.

Also, I'm not sure what you mean by pce community (unless you mean past posts or such). The PCE community is mostly at PCFX forums, and I believe almost all of them know the PCE doesn't have twin processors. But curious, why is it so hard to believe it's running at 7.159mhz? I think it's much more incredible that the VDC can run in 10.7mhz dot clock mode (pixel). And yes, the rom speeds have no wait states( /RDY isn't on the cart port, only the back plane). They had to be a little faster than 140ns (I think someone asked that).

Speaking strictly from a video related standpoint, I can find absolutly no substantial evidence to claim that the single weakness of the MD configuration, namely sub palettes, negates the numerous positive aspects in any way.

It wasn't a one or the other type of deal. It was there and then Sega removed it. There's no evidence to support the idea that they created more hardware features to make up for the cut. And I think the evidence is dependent on the title and the graphic requirements. Obviously something simple looking like Sonic isn't going to be hurt by that. Playing it confirms the fact. Whether you think overall that it out weighs the positives, is a matter of opinion. I personally think the positives are out weighed by the negative in quite a few situations. Not *every* type of game needs scrolls like the ocean side level of TF4. A ton of games get by fine without. I don't need Shadow/highlight or vertical column scrolling, or any such thing. A second BG is enough, now give me more colors/subpalettes please.

I updated my analysis to reflect the true CPU specs and sprite table. I like those comparison shots. The only thing I would point out is that the differences in some objects or background elements would appear to be a mere palette choice difference if you looked at these shots through the actual composite outs. Comparing various cart sizes with CD-ROM games (without mentioning size differences) is dubious as well.

Also, the 16x16 16-color phraseology was for the purpose pointing out that 16 palettes were dedicated to the single background tiles and the other 16 were dedicated to sprites. Certainly less limiting than 4 palettes total, but let's not exaggerate the advantage.

On the RAM, I thought my parenthetical comment made it clear that I know the two can't be mixed. My purpose was, again, different than yours in the analysis. You seem to be hooked on weighing palettes versus strengths of other systems, I am trying to explain how the engineering/marketing perspective makes more sense.

We have to look at the big picture before pronouncing it "inexcusable". At a bare minimum as you said, the Genesis has a stronger sprite system and two backgrounds over the TG16. But it also has a more advanced sound system and backward compatibility with the SMS. You and I know that there were a billion engineering choices made before each system was released.

Both systems were designed to be an arcade system in the home (i.e. inexpensive). Both systems were also designed to be compatible with the previous generation, in the TG16's case for the purpose of porting code, in the Genesis case for the purpose of actually playing the SMS library. Whether or not backward compatibility actually hindered the system's overall graphic performance isn't the point, neither is more palettes versus scrolls/sprites.

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.

Now you might say that Sega should have cut chips and added RAM, who needs that silly Z80 and YM 2612 when PSG is good enough? Maybe they could dump the VDP and use the Z80 instead. Hey look, that PCE only has 8KB of work RAM, let's do that too and increase the palettes while crippling our significantly more advanced CPU. Now do you see what I'm saying? Take off the hypercritical eye for a second and look at what you're opinion implies about the overall MD/Genesis configuration.

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-88).

In searching for a screenshot of the Genesis and TG16 color palettes I found this 9bits palette:



Normally I avoid Wikis like the plague, but I decided to pop this into Irfanview and found that it only reports 302 unique colors. Provided this is representative at all, that's a whole lot of redundant colors in the palette alone. I'd like to see some screenshots straight from the systems.

This is supposedly more representative, and shows 512 colors in Irfanview.

I'm not sure why you put compatibility with SMS as some big plus. To most in North America, SMS means nothing to them. Of all the features in the Genesis, it's pretty clear doing whatever was necessary to get more Color RAM should have been done. I really think if they had been able to get a glimpse of the future they wouldn't have cut it down to 4*16. It may have been pricey and needed cuts elsewhere, but I think that Shadow & Highlight is a borderline on useless feature. Not sure what cutting that would have saved money wise but cutting that and maybe increasing the retail price to cover enough RAM for 8*16 colors would have been a wise choice in the long run.

You are ofcourse very forgiving of the Genesis's design. It's a nice system. I like it too. Honestly my only complaint about it's design is that Color RAM limitation. Other than that it all seems to be in good order. It can be dealt with but it's sad that Genesis is the only system of the 3 contenders that suffers this badly. It wouldn't be so bad if it had half the color sub-palettes. But having 1/4th the SNES and 1/8th the PCE is terrible.

Basically my opinion on the matter is despite possible reasons for the cut, I believe whatever their motivation was it was a bad decision.

SMS compatibility in the Megadrive/Genesis is a huge deal, even in the US. I bought an SMS in 1988 and a Genesis in 1989, then in 1990 I sold my SMS and NES for a TG16 *because* I could use the Power Base Converter to play my SMS library. To this day I know people who own and play SMS games on their Genesis, one fellow even cannibalized a PBC so he could play Ys on his Laseractive. I say all of that to point out that your opinion on SMS compatibility is just that.

I'm glad at least one of you has come around about the cost issue now. I'm working on a comparison page today for Legend of Xanadu II and probably Lunar Eternal Blue. So far the overhead scenes are in the 40-50 color range in Xanadu II. I'm having to use an FAQ to figure out where to go next. I'm also noticing a great deal of rather bland two tone tiles in the overhead scenes, they may have more than two colors, but they don't look like they do even in emulation.

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

One of possible reasons for this is pattern name format - there are no free bits for more subpalette select bits, they would have to cut something to make room for this. Of course they could've make this implicit - scroll and palette planes could have used different palettes, for example.

I just ordered Kaze No Densetsu Xanadu, the first one, from Japan. With it I'll be able to do a detailed comparison of emulation versus composite out versus any other title. From what I'm seeing via emulation, Xanadu is only exceptional in its gameplay and art quality, but a full comparison may tell differently.

-edit-

I'm still working on an emulation screenshot comparison between Xanadu 1&2 and Lunar 1&2 and Vay. I ran into a snag I've encountered before. When using default settings Kega Fusion produces screenshots well over the actual Genesis color counts. I had to start over with Gens 2.11 because if I set the windowed screen to default this seems to produce screenshots of the right color count.

At any rate, 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.

sheath wrote:SMS compatibility in the Megadrive/Genesis is a huge deal, even in the US. I bought an SMS in 1988 and a Genesis in 1989, then in 1990 I sold my SMS and NES for a TG16 *because* I could use the Power Base Converter to play my SMS library. To this day I know people who own and play SMS games on their Genesis, one fellow even cannibalized a PBC so he could play Ys on his Laseractive. I say all of that to point out that your opinion on SMS compatibility is just that.

That was one of the reasons I bought the Neo MD Myth flash cart - it has the equivalent of the PBC built in, so you can play SMS games from the flash on your MD. It even has the YM2413 FM chip in the cart to allow FM music with SMS games that support FM! Granted, Tiido thinks the sounds isn't as good as it should be, but he's picky about his audio.

I had Tiido make the SMS mod on my Nomad so I could play SMS games on it (using the Neo MD Myth). Portable (retro) gaming at its finest!

Sheath, you are correct in that it's just my opinion that SMS compatibility isn't something I think is a huge deal for the Genesis. But from my perspective back then I was completely unaware of the SMS. Never once saw it in a store. Ofcourse, I ordered a Neo Myth MD recently and do plan to try out the SMS functionality.

Oh and by the way I do play my Genesis on a standard definition CRT display. It had both Composite and RGB inputs, but I don't have a RGB cable for Genesis yet.

notaz, it seems to me they should have done like SNES and I guess PCE, and just had separate BG and Sprite palettes. No need for extra palette selection bits. 4 palettes for both BG and Sprite would be plenty.

The only thing I would point out is that the differences in some objects or background elements would appear to be a mere palette choice difference if you looked at these shots through the actual composite outs.

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.

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.

On that note, I'd be careful of using some emulator screen shots. For PCE, if you're using Magic Engine then make sure *everything* is set to default. It allows you to totally change the attributes of the color output. That might fine if you like that look, but that's not a valid option for screen shot comparison. Mednafen will always output native colors and pics for emulation shots. I recommend that over mednafen. Fusion seems to scale G at different steps than R and B (is this a left over scaling routine from 16bit color 6/5/5 for Windows BITD?) . You can correct this by running "posterize" on a graphic editor and use a step/level setting of 8. Also be careful that some older emulators output shots in steps of 6 (and one of the newer ports of Gens outputs in some funky but incorrect scale as well. Still better than the old format though).

Also, the 16x16 16-color phraseology was for the purpose pointing out that 16 palettes were dedicated to the single background tiles and the other 16 were dedicated to sprites. Certainly less limiting than 4 palettes total, but let's not exaggerate the advantage.

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

On the RAM, I thought my parenthetical comment made it clear that I know the two can't be mixed. My purpose was, again, different than yours in the analysis. You seem to be hooked on weighing palettes versus strengths of other systems, I am trying to explain how the engineering/marketing perspective makes more sense.

.... 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.

We have to look at the big picture before pronouncing it "inexcusable". At a bare minimum as you said, the Genesis has a stronger sprite system and two backgrounds over the TG16. But it also has a more advanced sound system and backward compatibility with the SMS. You and I know that there were a billion engineering choices made before each system was released.

This thread is about graphic output and detail/color. I didn't bring up sound or BC because it's not relative to this thread and would no nothing than to really derail the focus of it. Megadrive subpalette is inexcusable. Just as only having a single BG layer on the PCE/TG16 is also inexcusable. Both systems have tricks for getting around their weaknesses, but it's not enough to cancel out the weaknesses. Bring in BC and audio only clouds the discussion. But I'm gonna touch on BC since you brought it up. This also came up at Sega-16.

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.

Looking at SMS BC in context. The end of 1988 when the MD was released in Japan. SMS was doing pretty poorly in the US, very-very poorly in Japan. EU didn't get into its SMS crazy yet. Looking back now, SMS was a very poor choice. But if you look at who Sega was back when they were designing the MD, they weren't very popular relatively speaking. They were known as an arcade developer (among MANY). They also had a small user/consumer base for the failed SMS/Mark III. They needed all the support they could get, and every bit of cross over appeal from the SMS library - they thought could help. This is Sega, going up against two giants in Japan. NEC (albeit a new giant in the game world, but still a huge giant as a company. They even had their own IC fabrication plants) and Nintendo. But in reality, they didn't need it. The huge majority of Gen/MD fans didn't own or know about an SMS. The consoles success was never tied the SMS user base. 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.

Lets look at the cost of the SMS compatibility. You have the cost of the z80 processor, the dedicated RAM (not SRAM, but still not in expensive DRAM). You also have the dedicated SMS compatibility modes in the new VDP. SMS modes are nothing like the MD modes. While I'm sure some logic was reused, you still have dedicated/legacy logic on the chip. That isn't free. The MD modes are just some extension in logic and functionality on a gate level to the SMS modes.

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. Though I'm willing to bet that they could have also used the spare cost to go with a 12bit RGB output DAC instead of a 9bit one. That would have been an incredible upgrade. 8 subpalettes and 12bit DAC, that would have made the difference between the PCE's 32 subpalettes very small. And the 12bit DAC having an advantage over it just by itself being 12bit.

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 control. These were never attached to the 68k (or z80), but they could have easily attached them. Even by wire if the board design just happened to have missed it. That would give you all the sample playback you need. That's the simple approach. The could have added a smaller FIFO buffer system as very low cost to keep the interrupt overhead down. But even without it, cpu at 7.67mhz easily had the resource to handle the relatively small overhead.

Both systems were designed to be an arcade system in the home (i.e. inexpensive). Both systems were also designed to be compatible with the previous generation, in the TG16's case for the purpose of porting code, in the Genesis case for the purpose of actually playing the SMS library. Whether or not backward compatibility actually hindered the system's overall graphic performance isn't the point, neither is more palettes versus scrolls/sprites.

Having coded for all three systems (and having written NES emulation), I'd have to say no on the PCE side. I would say the choice of the processor arch, even though it's very custom in design, was a matter of of a few factors. And the same factors Sega decided on for the CPU of the Genesis. 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, even parts of it as 1:1. Arcade development doesn't take into account tight rom space. Arcades are known to waste memory on large 2D and 3D indirect sprite animation sheets. Arcades also have a totally different graphics system. That has to be completely rewritten). But I'm sure clock speed was a big factor as well. Of off the shelf parts, Motorola provided the best range of clocked processors. The z80 came in a few higher clock speeds, but the z80 is an inefficient processor for opcode to clock speed coupled with being 8bit, makes it a poor choice IMO. You have 65C02, but stock they weren't running past 4mhz at the time. 65816 wasn't available IIRC. But even if it was, the damn thing requires twice the RAM/ROM speed of the core processor all because of that stupid multiplexing of the upper address lines onto the data bus, making what would normally be 1 memory cycle to access ram - now 1/2 memory cycle (because 1/2 is needed to latch the data pins to form the correct address). 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 65x very fast opcode arch married with a high clock speed (higher than stock) and also with custom instructions, memory management, and DMA like instructions to fit the rest of the system - all on a cost effective custom core, I'm sure made it an attractive choice. Given the higher clock speed (very high for its time), the 65x arch+ high speed was just as much or higher priority than getting FC programmers comfortable in a small amount of time (small down time for learning the system). 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.

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.

Now you might say that Sega should have cut chips and added RAM, who needs that silly Z80 and YM 2612 when PSG is good enough? Maybe they could dump the VDP and use the Z80 instead. Hey look, that PCE only has 8KB of work RAM, let's do that too and increase the palettes while crippling our significantly more advanced CPU. Now do you see what I'm saying? Take off the hypercritical eye for a second and look at what you're opinion implies about the overall MD/Genesis configuration.

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.

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???

In searching for a screenshot of the Genesis and TG16 color palettes I found this 9bits palette:

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.

SMS compatibility in the Megadrive/Genesis is a huge deal, even in the US.

SMS compatibility was not a huge. Maybe it was to you, but you were a small representation of the Genesis consumer base. A new consumer to Genesis isn't going to care about playing 8bit games (a tiny library at that, and it lacked the block busters NES. A lot of the SMS games were simple and cheesy, sorry). They are going to want to play the newest/latest and greatest games. The difference between SMS 8bit games and even early Genesis release games, was HUGE. You'd have to be retarded at the time to spend your hard earned money on SMS titles if you own a Genesis at the time. Nowadays? It's a different story/mentality. These are retro systems. We (well, most of us) enjoy 8bit as well as 16bit games. Though, I did notice large of disconnect between the Genesis and Sega Master System over at Sega-16 (which, AFAIK, has the biggest single Genesis community on the NET). I think that's because the majority of Sega Genesis fans never grew up with the SMS and dismiss it to this day. A lot of them put down or dismiss the SMS. Which is sad because that's part of Sega's roots/heritage

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.

I'm glad at least one of you has come around about the cost issue now. I'm working on a comparison page today for Legend of Xanadu II and probably Lunar Eternal Blue. So far the overhead scenes are in the 40-50 color range in Xanadu II. I'm having to use an FAQ to figure out where to go next. I'm also noticing a great deal of rather bland two tone tiles in the overhead scenes, they may have more than two colors, but they don't look like they do even in emulation.

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.

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, then you might as well state the Genesis has roughly have the horizontal color resolution. 256 pixel mode has ~128 pixel res for color and 320/160. And then totally validate the "256 color mode" of EC games and such. Sigh....

One of possible reasons for this is pattern name format - there are no free bits for more subpalette select bits, they would have to cut something to make room for this. Of course they could've make this implicit - scroll and palette planes could have used different palettes, for example.

For BG yes, not so for sprites. Which is what the original discussion was about (not this thread).

When using default settings Kega Fusion produces screenshots well over the actual Genesis color counts.

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).

At any rate, 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. Artificial inflation. It's like taking a SNES screen shot of with (real) transparency math and saying, "look hundreds and hundreds of colors". Look back to my Bonk on Amiga example. And using it as sprites, like I said previously, kills your sprite per scanline bandwidth (not to mention double your VDMA requirements for frame updates). S/H has minimal benefit. If the Genesis has double the sprite bandwidth, you could have used it on player sprites of MK. Although you'd probably have less frames of animation overall (it kills your vram space for sprites by half, doubles your VDMA for updating sprites). Second, the PCE has no S/H mode! 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.

Here are some pics of Secret of Mana (2 I think? It's one of the 'Mana games) for SNES and converted to PCE palette:
















(PCE left, SNES right)

These pics are machine translated. That means the color depth is snipped on the lower bits of the R/G/B elements to make them PCE compatible. Hand conversion results are almost always better. But the above shows enough to make the point. Keep in mind, the PCE still has subpalettes left over since the SNES is only has 8+8 sbupalette capability

Here's a shot that I did just a little hand massaging to the original converted pic:


I only changed colors for the brick wall, nothing else. The picture could go many different ways depending on the tone I chose.


Again, some more shots:






From top to bottom: Arcade, Arcade with PCE palette, Arcade with PCE palette and rescaled for PCE low res then rescaled back up for correct PAR (needs some clipping though. only ~290 pixels of 314 wide image is needed/usable), SegaCD version. Obviously the PCE one is going to lack multilayerd BGs. Ignoring the second player Cody and the second thug onscreen, just compare the last two shots. The SegaCD one, the thug, looks straight out of an NES game. I'm not exaggerating.



The SegaCD original pic is only 35 colors. I clipped out the two guys from the arcade shot, used the 9bit palette that PCE/Genesis use, and reduced the colors to 36 (I liked the TIMER counter with purple in it ). But just look at the difference. 35 colors of one vs 36 colors of the other. This clearly show the limitations of the subpalette system on the Genesis. And more importantly shows counting colors isn't a direct measure of detail (one being a bitmap pic, one being a subpalette pic). And if I say anymore on this, I'll just start repeating myself again

Another note about hand palette optimization reduction and automated reduction. That 9bit palette reduction of the arcade original yielded 1 less color than the arcade. Through direct reduction by hand, I was able to reclaim the missing color in the flesh tone:

(arcade,9bit,9bit modified)

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).

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 control. These were never attached to the 68k (or z80), but they could have easily attached them. Even by wire if the board design just happened to have missed it. That would give you all the sample playback you need. That's the simple approach. The could have added a smaller FIFO buffer system as very low cost to keep the interrupt overhead down. But even without it, cpu at 7.67mhz easily had the resource to handle the relatively small overhead.

Tradition might've played a part here as well. It was very common for arcade machines at the time to use a Z80 as a control processor for whatever sound chips the machine had (usually YM2151 + some ADPCM chip). So trying to build a home system that was an easy target for arcade ports could've been an objective of Sega's.
I agree about the timer IRQs though - that's something I never understood.