MD vs. SNES

[tepples]

How about the plain and simple fact that 65816 is painful to develop for because you can't properly disassemble code thanks to CPU flag dependent, ambiguous opcodes

Like x86 is any different.

Wasn't nintendo also looking at a 68K CPU for the SNES at some point ?

There's a 68K in the CD-i.

[ReaperSMS]

Instruction size on the x86 isn't nearly as tricky to figure out on the fly, since you don't usually have code flipping between 16 and 32 bit mode on the fly from function to function.

[blargg]

How about the plain and simple fact that 65816 is painful to develop for because you can't properly disassemble code thanks to CPU flag dependent, ambiguous opcodes ...

An execution-based disassembler can (and can distinguish data from code).

[Sik]

Er, stupid question, and not to be mean, but what does all this have to do with the idea I've written in the original post? ^.^'

[tepples]

Er, stupid question, and not to be mean, but what does all this have to do with the idea I've written in the original post? ^.^'

It's called digression. Whenever you notice it, feel free to PM me the URL of the post at which the digression began (right-click the little page icon next to the post date and choose "Copy Link Location") and I'll consider splitting the digression into a separate topic.

EDIT: Done. Thanks for pointing it out.

[MottZilla]

Can't say that I blame Sega. In order to provide more bits for color base, nametable entries would have had to either double in width, lose flipping, lose a tile number bit, lose priority per tile, or use a second packed table (like the NES does).

NES nametable format: tttttttt / cc (for group of 4 tiles)
MD nametable format: pccvhttt tttttttt (sprites use same format)
SNES nametable format: vhpccctt tttttttt (sprites use one more p and one fewer t)

I thought this initially two but you can easily get around this without adding more bits to the nametables or sprites. Simply have more Color RAM, and registers that control which palette various layers use. So for example you could have 2, 3, or 4 palette sets of 64 colors. You could choose for Scroll Layer A whether to use the 1st, 2nd, 3rd, or 4th set of 64 colors for rendering. Same with Scroll Layer B (or Window) and Sprites. This would easily have allowed developers alot more color. You probably could have even implemented a cheap way to increase the colors available to sprites, or just added more bits to them as apparently they did have room.

I really think it's a shame Sega didn't see the need for more color to be available. Other than that the only thing I don't like about the MD is I think the sound hardware could have been better, or atleast I wish it was. But the #1 thing is colors available.

[smkd]

I thought this initially two but you can easily get around this without adding more bits to the nametables or sprites. Simply have more Color RAM, and registers that control which palette various layers use.

Even if it was as simple as just giving the sprites their separate set of 64 colors it would've helped plenty, like the SNES did. 8 palettes would've done so much for it.

I really think it's a shame Sega didn't see the need for more color to be available.

I agree with the 64 colors thing being the #1 issue with the system. Even in 1988 it seems really shitty when you see the PCE released a year prior with even more subpalettes than the SNES.

Games trying to force music that was not made with synths in mind onto the YM2612 comes second for me. Whenever a game tries and fails to imitate a real instrument (guitar power chords come to mind) it sounds absolutely horrible. Rock n Roll racing being an incredibly offensive example =p

[Near]

Each have their strengths; but overall the MD kills the SNES in terms of hardware. But I care more about the games, specifically my favorites: 2D role-playing games. It's for that reason that I care more about the SNES than the MD.

MD had Shining Force 1&2, and if you can call it a game, Shining in the Darkness. SNES had FF4, FF5, FF6, Chrono Trigger, Seiken Densetsu 2&3, Der Langrisser, Lufia 1&2, DQ12R, DQ3R, DQ5, DQ6, BoF 1&2, Bahamut Lagoon, Rudora no Hihou, Emerald Dragon, Tales of Phantasia, Star Ocean, Terranigma, Aretha 1&2, Earthbound, Daikaijuu Monogatari 1&2, Far East of Eden Zero, Illusion of Gaia, and on and on.

[MottZilla]

Even if it was as simple as just giving the sprites their separate set of 64 colors it would've helped plenty, like the SNES did. 8 palettes would've done so much for it.

I really think it's a shame Sega didn't see the need for more color to be available.

I agree with the 64 colors thing being the #1 issue with the system. Even in 1988 it seems really shitty when you see the PCE released a year prior with even more subpalettes than the SNES.

That's what really bothers me. The SNES came after, so you can't say Sega was stupid because SNES supports 256 colors. But you can say that the PCE Engine which I think has 512 colors in its sub-palettes was right in their face and they thought or didn't think about how 64 was not enough. That's why the Sega CD was a real drag to me, since the #1 upgrade that would have made it look much better would have been a VDP upgrade that results in more color. The 32X breaks the color barrier, but came too late, and broke the bank too. Plus I think that the 32X is all frame buffers and bitmaps and not your typical PPU or VDP setup with hardware sprites and background layers. I suppose just since it seems like such a minor change could have had a huge impact it's so bothersome. I can't imagine it would have cost anything significant to have add more palette RAM to give BG and Sprites seperate palettes. And I've always said even if it did add cost I think they should have cut out Master System components. Like the Master System only modes left in the VDP.

[Sik]

That's what really bothers me. The SNES came after, so you can't say Sega was stupid because SNES supports 256 colors. But you can say that the PCE Engine which I think has 512 colors in its sub-palettes was right in their face and they thought or didn't think about how 64 was not enough.

I thought the PC Engine had 16 sub-palettes o_o; Oh well... And then again, their arcade systems allowed up to 4096 colors in some cases (talking about those on which the MD is based).

I guess it all comes down to cost, since the MD wasn't exactly cheap on launch from what I recall.

That's why the Sega CD was a real drag to me, since the #1 upgrade that would have made it look much better would have been a VDP upgrade that results in more color.

That'd have made the Sega CD much more costly due to requiring yet another custom chip. Not only that, but the extension port doesn't have any way to feed video signal into it, so it'd have needed to use a wrap cable like the 32x did.

The 32X breaks the color barrier, but came too late, and broke the bank too. Plus I think that the 32X is all frame buffers and bitmaps and not your typical PPU or VDP setup with hardware sprites and background layers. I suppose just since it seems like such a minor change could have had a huge impact it's so bothersome.

Yeah, the 32x only adds a framebuffer (double buffered, actually), but the VDP layers still are available so it's possible to use the tilemaps and sprites. Now, the 32x does software rendering in the framebuffer, which is why it's so slow...

I can't imagine it would have cost anything significant to have add more palette RAM to give BG and Sprites seperate palettes.

Yes, it was, especially when you consider chip space. The kind of memory used on CRAM probably eats quite a fair amount of chip space.

And I've always said even if it did add cost I think they should have cut out Master System components. Like the Master System only modes left in the VDP.

They did, they removed 4 of the 5 modes supported by the Master System (which didn't matter since only one Master System game used one of those). The main reason why they didn't remove backwards compatibility is because the Master System was successful in Europe and they didn't want to lose the market share there.

[blargg]

THE thing that always drove me nuts about the MD was the ugly columns always visible in the composite video output, due to them not varying the color carrier phase each scanline. Scroll in a game and as your eye follows moving things, their columns widen and narrow in a very ugly fashion. The SMS had the same problem, and they never fixed it. Hell, even the TI 99/4A had the problem. They all used the same graphics chip line.

[TmEE]

I personally think the fixed phase setup that SMS and MD use looks far better than what Nintendo and everyone else used... I absolutely hate the fuzzy edges that NES, SNES, PSX, Saturn, DC, N64 and all other machines produce...

Luckily there's RGB and all Sega machines starting from SMS do that so I'm happy. Now if someone makes a NES PPU replacement that does RGB and has those bugs I heard about that PlayChoice10 PPU has fixed up, I'd be first in line to get some, no matter if it costs 100USD per chip

[Sik]

If I recall correctly, one of those methods looks better for still images, while the other looks better for scrolling images, so yeah, I guess it's a tie when you consider that. In the end both suck anyways =P

[psycopathicteen]

A major downfall for the Snes is it's sprite management.

As I've already mentioned the Snes only having 4 sprite sizes, pick 2 at one time. One hardware sprite on the Genesis might require several hardware sprites on the Snes. This means that eventhough the Snes has 128 sprite entrees and the Genesis has 80, neither of the two has a clear advantage of having more onscreen objects.

The way 16x16, 32x32 and 64x64 sprites are decoded is annoying. On the Genesis a 16x16 sprite with a tile number of $00 would take up tiles {$00,$01,$02,$03} while on the Snes they take up tiles {$00,$01,$10,$11) requiring 2 dma loads instead of one. This is a shame because 16x16 sprites are more useful in games than 8x8 sprites.

Then there's the fact that the Genesis can use up to 2048 tiles as sprites just as long as you give enough room for backgrounds, while the Snes is limited to only 512 tiles at one time with 2 moveable banks.

The way it is stored in oam is also pretty dumb, because on the Genesis you have 16 bit x and y coordinates, whereas on the Snes you have 8 bit coordinates. Then how does the Snes scroll sprites off the side of the screen you ask? After the main part of the oam there is an extra 32 bytes with the 9th x bit and the size bit for every sprite is stored in an interweved pattern.

What the hell were these people thinking?

[MottZilla]

I thought the PC Engine had 16 sub-palettes o_o; Oh well... And then again, their arcade systems allowed up to 4096 colors in some cases (talking about those on which the MD is based).

I looked it up to be sure. The PC-Engine supports 16 subpalettes for BG, and another 16 for sprites, giving that 512 total.

I can't imagine it would have cost anything significant to have add more palette RAM to give BG and Sprites seperate palettes.

Yes, it was, especially when you consider chip space. The kind of memory used on CRAM probably eats quite a fair amount of chip space.

And I've always said even if it did add cost I think they should have cut out Master System components. Like the Master System only modes left in the VDP.

They did, they removed 4 of the 5 modes supported by the Master System (which didn't matter since only one Master System game used one of those). The main reason why they didn't remove backwards compatibility is because the Master System was successful in Europe and they didn't want to lose the market share there.

I have heard both of these reasons before. While it may have cost something significant for 64 more colors and the logic to use different sets for BG and Sprites, I really think it would have been worth the cost. As far as Master System compatibility, perhaps they could have cut it from NTSC versions but retained it for PAL. And also I have always found backwards compatibility to be a luxury feature and not essential. Afterall, if you own SMS games (back when the Genesis launched) then you already own a SMS console. Would you really want to buy PowerBase converter just to play them on this new console? I think the money spent on Master System compatibility was money that could have been much better spent on improving the MD/Genesis hardware, which was the future and the whole point of the product's existence. Scrap SMS, add more colors, maybe more sophisticated sound, suddenly you may have a system that is a whole lot better.